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e-p rofil e *Interface; 



s% e ci?T P clTT0 r S f ^ f n \ nt 3Ce «y found in 
- Volley and Wolfgang ntrks, datL^"?^ ^fl.'" '^^RE" bv 

'■ ■""u",J 1 " nCr01 UnM to/f ™ ^ Annie Interface Card: 

* i ^rd bi \ s %? s V„rible ( f :r Pa V tV — ^ cable r, e 

controller calculate oarit^onlv -I ^ 0ni - ori ^ this signal: t^l 
the controller does not check oari, h ' ***** * V ° rd * c "* s the bus 
instead the parity bit is L "eneraLd * ^ iS S6nC frora ^ Ho | 
of the bus and then routed bac^o the ho't^ °" ^ —Her side 

C!D ( Comma nd/.Vtfnt 1 ' on- i e .„. . .• 
™- signal is one-;V^ot^Vl ke h %I: S n ::. ACtt - ^ ' 

*«P m mind that even though the ^ lnt «*«e . 

utonomous ^chines, the host C and ' Stroller ar » Cwo 

controller the slave ( In ?M S ^nfiT - « 0nst ?«* the ^ster and s e 
to initiate a transfer o c iT ' °" ^ ^ the ho *t vtshes 

discussed below ) is acttv. if ,Vv / ' ' tMt check * ' ? 

"hlch the contrSller c»n oiTif rt ? ' *'? S tMs ls th « 3f ™l »lt1 
on Che Hus^ " SlS " al " th « ««er.ll.r/h..t M lr t ha C „«. wl M 

condition is true for Write. h ° St and che onposite 
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p -of ile*CommunicationW?rotocol : : 

The following is an explanation of the protocol that is used to orovide 
communication between the host and the controller: 

5one explanation of the symbols that I am using" is probablv called for at 
ins Doint. ) ! 

. ■ : T'-.a h racket symbols mean that the information inclosed wt-Mn t-en 
- nana i to tv . 

>.' : The square bracket symbols mean that j^e information inclosed is 

• The vertical bar symbols is used to indicate an alternative or "OR" 
Edition, -or example, A|B can be thought of as Either A OR B". 

= ' : This symbols is used to indicate a definition or equivalence. 
: Curl;/ brackets are used to denote comments. 
: The plus sign is as an addition symbol. 

Z^Kul ^ is ^y w ° rd indl ^tes the emp^y set, or in some cases, the fact 
^ Che .unction whose value is NULL can he ignored. An example is: 

Argle-Bargle ::-\jTULL^ 
^sentially you can foraet .that Arg-le^Bargle" exists for this context. 
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TKEN Instruct ion«Byte : :* < 

Read* ID | 

Read*Controller*Statu.«5 | 
Read* Servo* Status | 
Send "Servo* Command | 
Send* Seek | 

Send*Restore | 
Set^ecoverv '. 
Soff*Reset I 
Send M Park | 
Diag"Read I 
3iae*ReadMeader t 
Diag"Write | 
Set*Buf fer^Ptr | 
Read*SpareTable i 
Write'SoareTabLe | 
Formats-Track | 

Initial i 3 e*SpareTabie | 
Read* Abor tus tat | 
Reset*Servo | 
Scan > 

ruction«Parameter«Strine ♦ •» / -nw- i - 



" ,1,Scri?t *"3et Fi-rmware Specification Pa?e 9 



"ID ::- < S00 > 



ruction«Parameter*String : :-<%JLL> 

diagnostic command reouires Wideet to 'HetfwLr c« '.v* v ■ „ 

ific information. ^ e structural f^,^ J I Chfi h ° St 3ome device 

e s - ruc turai layout of the data returned is: 



• T'JRE Id e n t i ;iv*3Ioc'< 



vou L viU S ^ V^U" l:U ne ' S '"' V Che structures contained „u M n 

■'ir- =7r , U , ' comment is etven exnlainina the tv D p Q f 

7, ; f ' d < * en ei5nenc r ™« ^ f, if t-e entir- struck 

' nt or *s a Linear arrav of bvt»s t -Wai- v„„i j fcU . s,rJC - ire lb 

rf s trl „ ? ; ;irlt cL event to-U %*^et»Vr/ hi : ST.Tij^T ' 
- .tring. and is Located l„ byt.. 30 thru « of *tn s ^ re turned" Mock 

"anuria, : : . -VUrtt-tJ ' / 13 »„«./»«. rtCi Ascil nri« ^ ' 

OevtceTvoe : : . o e „lce . Mid g e e+Kid set . StzcVtf ;e t . Tvoe ! T5,te..'SdD -SJIP 

3ize«20 : := <3 L0> 
Size*A0 : := <320> 

Widget.' 5 ™ S refSrS t0 ^ ^ ° f fi ^ Ware l» bedded in 

System firmware will not allow the hncf i-« r T , 

Diagnostic : :» '<«0l> 
Fimware-Revision <{ 2 Bytes/ S 10 : S 1 1 }> 

.aoacitv ::. <C ao*10 , , , , , vtM/ , N 

Can* 10 • •- 



Cap"20 ! 
Cap" 40 : 



<S004O2J0> 
= <S009K00> 
- <S013000> 



3ytes»?er*Block < S0214 { 2 3ytes/S15:lft }> 

:umber«0f«C7iind«rs ::- < Cyl-10 . C vl«20 > oi«4« f 1 ^vt-s '< l"" ■ ci 9 



Ol*20 
01*40 



<3020:> 
C30202> 
<S0404> 



'unber*Of*Heads G02 ( L 3vta/St9- \> . 

COfwSectors : :« . 
5ctr* I 3 : : = ,'3 i 3> 



- ec " 5rs ■• s 3Cwr<13 f ictr-»20 . ■. .^ct^4 : 3 /■ I 3y,te ■' 5 1 A 



Rearf*Controller*Status : <301> 1 v . • 

Widg^^in^ t a u V n °l r : t Ci T 0n C ? mPlSteS { c eiChe ^ successfully or exceotional I v } 
gec liL retu ™ w hat I rerer Co as Standard*Status , thus allowing ts- u„ aP 
sys em an onoortunity t0 change It's *low of execution based o i / 
status. Morally this Standard-Status is all t^t is necaasarv to ensure 
continuous operation. In the exceptional case, or when the Host svstem 

te or— * COnCr ° Ue /' s Actions, additional information co „ce r 
- te or , ld get is mandatory: without it the «ost simolv could not make "an 
o K Limum choice in deciding a course of actioq. " ■ 

"urtS^^i^n^r 8 / S ! meanS f ° r the ' H ° St SVSte!n Co interrogate Vidwt 

co^and and is d. S { ^ eXCeptlon of AborfSeatus. which is"a seoerate 

da™ structure. di3 T S6d P Ute l ln thiS doc M^nt } belongs to a homogeneous 
L^ZIZ r ly ' four ^ q««ntlcy containing a bit map representing 

a ous excepdoaal conditions {. active high } that is available as he 

co^and 7 " Caad fr ° m Contro11 " -PO" completion of the current 

specie a s Lrr n H StatUS ' f Vatlable t0 ^e Host svstem. The Host requests a 

corres'ondA, 7 Inst ^^^*^rameter-String to the value 

corresponding to the status needed. 



IF ( Instruction*Byte - Read"ControUer"Status ) 
THEN Instruction*?arameter ,, String ; ::« < 
Standard*Status • 
Last«Loe;ic;-il*3lock' t : 
Current*5eak*Address; ! 
Current*Cvlinder | 
Internal M Status | 
State*Registers I 
Sxceocton^eaistera > 

'he -'our hvte rasoonse to each f che 4hove r , 0ue ,.. fl ^- ; .„ e 

Result < Ryteifl 3ytel ^yte2 ^vr.e1 >. 
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Lasf»Logical"*Block : :» < S01 > ! ■ 

Byte0 : :« < S00 > ! . 

Bytel ::- < { Most Significant 3yte of !Logical«*lock*Number } > 
3yte2 : := < { Middle Byte of Logical*Si;ock*Numher } > 

Bvte^ < I Least Slgni'icant Byte r>r[ V^i^l^hcWn^: ■ n 

Current*Seek*Address ::= < 302 > 

3yte0 < Most Significant Cylinder Address > 

3ytel : :- < Least Significant Cylinder Address > 
3yte2 : := < Head Address > 
3yte3 : := < Sector Address > 



Current*Cyiinder : < S03 > ^ 

{ The Current*Cylinder differs from the durrenc»Seek"Add ress in that'it is 
under certain circumstances; for example* the drive mav have been bumped } 



3yte0 
Bytel 
3vte2 
3vte 1 



< Most Significant Cylinder address > 

< Least Significant Cylinder address > 

< 300 > 



< S00 
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Bitl: Ram^Space^^ enabled 

Bit0: IF active THEN controller LSD , should be ON 

{ The Rara*Spaces mentioned ' above are 5 2k address spaces overlaved on too of 
one another to provide the controller with ^he abilitv to keep' several r^sk 
blocks temporarily resident in ram. At {he tine of this writing, however, oniv 
Ran* S pace* is being used. } \ 

3yte3 .: :* < { Registsr: Oontr il l^r^$tafis H ?or t • 
Bit7: CrcError { active Low .} 

{ this bit is valid ONLY when the controller state 
machine is **0T in reset, which should be ever? tine 
that this bit is read by the host. Therefore, if this 
status bit indicates a CrcError, then something has 
croaked. The normal ; way for the host to check if a 
Ore or Sec error has occur**!, is to examine Status: 
"xceotion^entsters which are i ieussed below. 

Bitfi: "r i te^Not^Val M ( active low } 

{ as -in ■ CrcSrror, this bit is -/al ii onlv w^eo' t'^e 
state machine is NOT in; reset. The information 
expressed by chia bit la converted into- a .tv*« of 
Serveerror, which ia , found in Statue: 
2xeeption«Registera. } 

Bit5: ServoReady 

Bit4: ServoError 

{ the.eervd status bits listed above axe further 
explained ia Appendix A: Serve Processor 

Documentation. Essentially the two bits combine to 
form four possible servo states; the normal condition 
* ^ is ServoReady AND ( MOT Setv^.t.^ ). ) 

ZLz2:$ Currant controller state-machine state. 

f as in CrcError and Vrite*Not»Val id , these ^Ulus 
bits are valid only when the state -.ac-i-e v« vnr in 
reset, and, should read 300 any other, time. „ l 

On the surface it appears that this byte is" or limited use for non real- time 

situations. It is, however, invaluable in itrving to decide if the >ervo 

processor is healthy, wealthy, and wise. : tt 'also orovides a -eans' = ->r 
diagnosing a sick state machine. . . 
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Read*Servo»Status : := < $02 > ^ 

Instruction-Parameter«String : t» < | i , 2 i | 3 | 4 , ^ , a ( 7 , , s 

This status command is used to InterrnoarL Vv.* n 
same vav f^t Read"C™r r ^1 1 ^.Jf. \ g ? S6rV ° ?roca ssor In nuch the 

i* m * ContolleriStatus is used. In fact, the 'om of the r*«»..T- 

the sara e four byte hl:-nan P ed quantity ul " 



t.ne servo processor without i L^antl i- 2 



i-IaSt da 

e 

hit 



desc''iot!;n Re o" £ AP ° endiX A! S « rv ° ^ocessor Oocu^nt^'lVn for a co^ole^ 
-esc. lotion or the various status' avaH ahl a ^a m • . , ■ 

descriptions. JvaUdbla dnd res.utine hit 

Send H Servo** Command ::= < S03 > 

InstructionaParameter-String : < By te0 lytel V/t-2 Svte3 > 

>' ™Uy, the « oat will allow the controller to -.annulate t-e se^-o ^roc-ssor 
1.. order to perform useful { or „avbe not so .-s-ui ' 1 V r , nr 
let s suooose that the Post svstem wishes to \£l X ^ ^ LiT° ' 
pe n rfor k th\° T^V Under n0mal -^rattn^condUions't;: " r f av ": 
However, the dost has the caoabilitv to bvoass the controller and direct the 
head" r "rthe r 'sel^^ % HosC , c f n t"« ^ servo command to oosit on the 
to he controller 7 , C < °™' nd } . SO that seek is completlv transparent 

eeen^Lr^^V^T'o^the^Vtr^ U S ^ ~' " ^ ^ *°' C ^ 

A: Se^Pro^O^^ thS "™ C °" «» ^ ^'i- -nendi, 

* 

Byte0 < S*Command + S»Directicu + Hi»Magnitude > 

S "Command : : » < 

Offset 

diagnostic. . 
DataRecal 
FormatRecal 
Access , 
Access«Of f set 
. ( y ome 

Offset : := < 310 > - . > 

The Offset command allows the *ost- to microsteo t^e '-eads < n -'^r 
a positive or negative direction from t^e center of ^e cra C v"-v e 
-idgac firmware does not nake ■ use >f this. Mature! I h av . Ln^ar 



-ett^t-is to ^ -tore soeci-"ic ^ata recover-/ , r ^.^ ,■ 
:..e ~ost. ~- value *nri , \ • rectlon, ?f f-e -,ic.^sr,n 
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S*Direction : •- < Positive | Negative > 



^"Magnitude ::= < 'A i f .'•>', ] ■ ' 

. racks • \ * ' ~ Che head.s « -mltl^e -" 2<< 



3ytel < Low-Magnitude ::- . . - 5 5 > 

Byte2 ::- < Of f set "Direcctori + Auto'Off set-Switch + Of f set«Ma*nl tud e > 

-1 

s command bvt-e, when i.e fl J ... 
and direction of iicroatepoVngf """"'^ » ««abilshe, ;s e ^esrae 

Offset*Uirection < Positive | Megatlve > 

Illicit ::: < 2! ! °L fset cowards outsWe > > 

•Negative . < S 00 { offset towards' inside diameter } > 
Auto»Offaet«Swicch < ON | OFF > 

this command ) > ' ' d ° not aut ° ««« on 

Offset*Maginitude ::- < 3. .3 2 > 

3yte3 < Baud«fR a te + Power»On"Res«'tr > 

3audiRate < i9.5k«3aud | 57./tf«;W > 

■* 9 

The servo 'comes 'uo' at iq - -j 

wjiues ud at I -*.-;:< oaud because- o- ~'-a 
eauioraent used an it s f„, a i, . . e 1 - e 

Once' it it r * ^ beeore integrated into * svst-n. 

, U . la wnnlri, ,, Uh a controller, however, ^ h ^ ' 
contmuoslv at 57. nk s*tui 

\ Sdud. ,his .parameter.- is also -a 

■nihLeadinj :n that once t^e servo '••as v«« - >n -V ~ 

' :or *"« r ' '-his parV-ieter: - vn r -V-' 

1, ^sl.Le "to- ,o -Torn -e > i2 her rate V — A-^ 

-it.iout reset.1^ the ^er'vo'orocfessor. ------ 
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Send* Seek : : = < S04 > 

Instruction»Parameter«String ::- < HiCyl LoCyl Head Sector > 

any track on the disk. The value of the seek address sent in the 



parameter string is used read/write a block of data usi\Tth e r 
co^ands for those functions. For exa.pLe, for the , & a ? VJlt 

f J' Se ^°I 18 * S^WCon^and would be issued For chat tL^lT^ 

or ./Under, head , *nd sector { SflMl 00 12 * < w> , ^ - * ■ 



I 
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3et*Recovery < 506 > 

InstructionMParameter^String : < ON | OFF > 

ON : := < $01 > 
OFF < S00 > 



!L^ bMt ; f my ,**i] lty 1 have "tempted to make the exception handling 
-SuMctjnstics of Vidget a binary set: either Wid 2 et handle, —rvr^ 
or ..ie .est system does. The command Se t^Recoverv ts t^e TJ ost'? < M> v' ^ 
t..is all or nothing world in that it is | through this ins true t ion " that' >he 
^ost can gain control of the media. When Widget comes ud after be in* 
reset it assumes control and sets Recoverv to he ON. The Most r/st- 
overtly change this state { via Set"Recpverv } if it wtshes Co ' e muTatp a 
different exception handling criteria. Once Recoverv is if* r^t 
controller will always fail tn an operation if an exception occuri: the 
^ost system ,fUS l assume responsibility for ALL error handling. 



ill 
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Send'iPark : : = < 303 > ■ .! 

Instruction*Pararaeter>'String : :» < NULL > 

TrTt^y^ X SS T, a Sena " Park coramaAd to the controller the results 
are that that the heads are moved off the data surface and held verv near 

It \2£t dia " 6ter C 5 aS J 3t0 °- The difference, between this command and 
the S e nd«Servo«Coramand: Home is that Home is performed 'open-loop' with 
the crach stop as it's reference point, while Send*?ar'< is an ac-ess 
-onmand c 3 * speciric track. The net result is a fairlv heftv saving 'of 
"Seneca* C ° mmand Can be an order of magnitude oulc'<er tnan 



/ 
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Sync : < 30100 > 



/ 
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3ef«3urier*?tr : :» < B : dC > ■ 
Instruction"?araaeter*String ::•(.< HiAdr > < LowAdr > } 

HiAdr ::- < Most significant byte of buffer address > 
LowAdr < Least significant byte of buffer address > 

The Set*Buffer"Ptr command is externally. { in the host's point o<= 
lden . tical t0 * command: The *ost Control ; er handshake 

' , ~ s \ 3 rav -i**s .wUh the appropriate resoonses and -h* '-'est 
reads rrom t^e controller's buffer area to receive data. Tn this 
instruction sequence, however, the host does not read a block of 
'-ata rrora the disk, but rather an arbitrarv number of bvr- a *r*m an 
arMtrary location in the controller's ram space. The *ost also has 
t.e ability to wrUe to this ram space - in effect trashing all of 

s to°a loL rH 3 H brainS if l 5 S ° deSiraS ' The intent of this command 
is to allow the Host to perform diagnostics or read variables that 
•*re otherwise not available. 



/ 
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though of as a linear -array of bytes ♦ -he a °tr is used to 
index into that array }■» To arrive at the actual index 
value within the Heap, the Ptr must first he multiplied hv 



tour. 



When a di3k is formatted and fresh data is being written to it, each 
logical block is asigned the first available phvsical block on the' disk. 
Therefore you would expect that LoigicaniockC ^ would occunv 
PhvsicalBlockf ), L(l) — > P(H 4 etc . There are instances, however, 
vh - n - 1 -lock of data lust he relocated to another space on t^e disk t'-at 
does not follow the original progression { for example, t u e original 
space was defective }. In order to 'find' these relocated blocks in the 
- iture a record must be kept as to where all these relocated blocks have 
been put. This record takes the form of '123 linked lists having the -"om 
HeariPtr(n) — > LinkedList(n) , where n :- 0..127. The algorithm for 
deciding whether or not a Logical Slock ' has been relocated is to extract 
bits 16:10 from the Logical 81 ockMumher and use it as an index into the 
HeadPtr*Arrav. tf the HeadPtr associated with this index value is Mil 
chen Logical <Uock has not been relocated else use TeadPtr.Ptr to searnh 
the linked list corresponding to this- HeadPtr value. Now to decide if che 
LogicalBlock has been relocated a test must be made as the linked list is 
traversed by comparing the LogicalHlockNunber ' s bits 9:0 to the current 
list element's token value. If they match then LogicalBlock has been 
relocated and it's new position is a multiple of the list element's 
position in the Heap. / 



SpareCount : : =» < S00..S4C > ' 
3adBlockCount ::=> < S00..$4C> 



3itMao ::- < ARRAY [ 0..S4F] of 3itsY> ' ■■ 

The bit map is used to , keep a record of which soare blocks are 
occupied, and their locations on the disk. , 

Heap :: = *< ARRAY [ 0..S4B ] of ListFAement > 



ListElement : :=* ( 

< Mil+fj se d+fTgeable+Spr^Type+ r )ata ,, Tvr>e > 

< Token. > ' 

< Ptr > ) ' - ' 

Nil < S80 { IF Nil T^EN Snd«05"Chain 1 ^ 

'Jsed : :» < $40 > " 

Useable : :» < S20 >*' 

Sprlype < Spare : 3ad3lock . "> 

Spare : < 310 "> ■. 

3ad31ock : :« < 300 > 
Data* Type : < Oata ! ^oareTabU > ' 

Data : :» < 302 > 

Spare-Table i : : * '.' 3-05?. v- 
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Instructlon-ParamateriS.tring : ( < $F0 > < ! S 7S > < $3C > < SIE > ) 
This command allows "the loaf 

"are tabid locations on the Usk. 



/ 
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-ni:iaii2s-' , SparaTabie. ::- < 313 > 
Instruction ! *?araraecer J 'Scring : :* ( 



< Foraat^Of fsat > 

< Forraat*Tnterleave > 

< Password > 



?or-iat*Of£set ::- < S00. .Vumber«Of 'Sectors > 

Po^at^ter^ive ::- ' J?*..*^ / interleave factor } > 
Password ::- ( < 3F0 > < S 78 > < S3C > < S1E > ) 

This command for. the Most instructs the controller to 'wioe -e slats 
bitten to "iYsk? 6 3Par9TabIa tS «««rned. 'he initialized .able is 



/ 
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3eset*Servo : : = < 3 ]_ 2 > « 
Instruction*?arameter«»String : :* < NTJLL > 

*eset*Servo allows the hose to initialize the servo orocessor without 

t' slrvo TV?* d " 1 1Ca ' d0Wn - ™« controller crtU Vtc^ticai^«a« 
the Servo, check for valid initial conditions and. ner'orm a n a ta-R eC al 



9 
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Sys^Read : :=* < $00 > 



Instruction*Parameter*String ::- ( < 31ock«Count > < LogicalBlock > > 
31ock*<Count < $00, .$08 '> :.- 

This parameter is the number of! blocks to be r«*H * , , 

blLw f ^? • , / read ' the 'IwWount the number 

blocks following the F irst one that is to be read, also. 



Logical3lock 
LM0MS 
L"*20MB 
L*<i0MB : 



< L M 10MB ! L*10>!S I L'^MB 
= < $000000.. 30063FF > 

- < $0009)00. .$0097FF > 

- < $000000. .3012FFF > 



/ 



mm 



HANDSHAKE PROTOCOL 

3oth Widget and ProFile share the same «ost interface scheme, and ^pfor, 
?ro^i^ C n°T n T ^ C0m6S C ° tr:,ln ^ to tunicate wi;S t^e -est" svs\^ 
o^o vLr^o^ad u'° CUmenCed ^ ' Pr0FUe ; C «™^«tl,n -roeocol' for* lis* 

The actual seauence of events can h e portaved as foLLows: 

?rotocol*Sequence : : » ( 

< Initial*tfandShake > 

< CoramandWDownLoad > 

< Response*Hand Shake > 

[ Oata«Received"HandShake 1 

< Final ""Hand Shake })'■'.. 

Initial*HandShake ::■ 

1. Host asserts CMD , sets data direction to read 
controller asynchronously responds bv: 

a. Writing S 01 to the Host*; 

b. Asserting BSY \\' _ 

3^ If the Host recognizes the controller resnonse, it will resnond 

a. Writing a S55 to the controller 

b. Otherwise it will write a SAA 

c. In either case the Host will de-assert "MD. 

t ■ t ■ 

4. The controller will respond to- the float bv: 

a. In either case { whether the Host resoonded. with a SS5 or 
SAA or anything else } the controller will eventual! v end uo 
waiting ..or the next instance of'CMI). 

b. If the response, was a. 3 5*5 then the controller vf i ^ e a 
captive audience, anxiously await ina instruct -ons -"-^ 

J .ost is to what to -lo'next. '' 

c. Otherwise, the controller- will Abort, and leave Standar- 
otatus saying so tn it's buffer where the host :an r*ad ^ 

°i u ■ t; -«. command seauence :for the controller r>en heco-ies 
,nitiaiaHandbha<e, -and. the ^ost. should . read ■ :o it's 
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5. The controller then -asserts 3SY 

6. Assuming the Host accepts the : resoonse from the control »r 
will respond by writing $55 back to the controller and" then 
de-asserting CMD. 

7. The controller will then continue executing the. comnand . 
r inal* Hand Shake : 

1. ''Then the controller finishes with t"->e exec-it ^ 
instruction, 

it will put the latest Standard^Status in a location ■• u'<5 
buffer ! 

where it wilL be accessible to the «ost f a« v«" ' a S J ata 

that 

might be a result of the command execution }. 

2. The controller then de-asserts 
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COMMAND SI3MMAKY 

?roFIla«Coraraands: 

ProFile^Read : :- ( < $0 0> < 3 bytes LogicalBlock : > ) 
Pro*ile«WrV«rify : :- ( <$0 2 > < 3 bytes Log.tcalB.lock > ) 
3 iagnostic"Commands: 

Read" ID :: . f < s { ?> < S #0> <SEn> > 

?p:^° ntr «c Lier " Stat:US :: " ( <Sn> <S0l> < Status ^ < Chec^vte > ^ 
Itt^ *r tatUS !: " ( <311> <3i,2> < S ^tua > < CbeckSvta <> ? 
Sandi,ervo«Command ::- ( <Sl*> <S03> < 4 comniand Svt „ > < Che^vt- > ^ 
-n^Seek ::- ( <^> < S 04> < 4 bvtes cvl /head /sector > < CheckBvteV^ 
Send-Restore ::- <S13> < S 5 > < Data/Format Recal > < CheckBvt- Y ' 
Set«Recovery ( < $n > <s06> < 0n /Off •> < CheckBvte > ) 

Soft-Reset = ( <S I 2> <S07> <$E6> } 
Send "Park ::= ( <S1:> <3 ^ a> < 3E 5> ) 
3iag*Read ::= ( <SL2> <309> <3E4> ) 

Dtag-ReadHeader ( < 3 L3> <S0A> < Sector > < CheckBvt- > > 

Diag^Urite ::- ( <S 1 2> <S0B> <SE2> ) ' 

--t-JBuffeciPtr ::- ( <$U> < S 0C> < 2 bv te s buffer address > < CheckBvte > ) 
*ead*SpareTable : :- ( <S12>, <S0D> ^ SF?> \ , ^ -nec^vte > ) 

Vrite*SpareTabie ::- ( < S \$> <S0E>^S8-n") ! ' < ^ S ^V * iJft^oJaiuO 

InUi'iJr^c < sA> <S0F> < 0ff M* > < Interleave >*7^7ckBvte > ) 

initialize«SpareTable : :» r— *— < fA1SWm<.t!> 
, 9J , NS , C <S13> < of fset > < Interleaved CheckBvte > ) 

Read"Abort*Stat ( <$12> <$11> < S DC> ) ' 

Reset*Servo ::=» C <S12> <S12> <$DB> > 
Scan ( <S 1 2> <$13> <SDA> ) \ 

System Commands: 

Sys*Read : :=»* 

C <S26> <S00> < BlkCnt > < 3 bytes LogicalBlock > < CheckBvte > ^ 
Sys'Write : ! 

C '<326> < S 01> < BlkCnt > < 3 bytes LogicalBlock V < ~hec<Rv t e > 1 ' 

Sys-WrVerlfy ::- ( < $ 25> <S02> < 3 bvtes LoglcalBlock > < CheckBvte > ^ 
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^is type of exception Widget if equiped tith 2 C ° Ch<m * e - T ° handl * 

error correcting device { although S! « V ! ° r detectin S devices" and 1 
correcting }. W f dgat ™ ^ /meeting and error 

all single-burst errors less than Lv, P ol ? noralal < CRC-lfi } to detect 
single-burst errors of sixteen bits * J lxt «*-*"« tn l «^. almost all 
sixteen bits in length. \ J" b J * ™i sl "^^urst errors greater than 

Meeting orooerties 9 s ,il ar to that of ^ ^ f 1S ° USed thaC has ^ 

Indies burst "of uo to 48 b", r / , " " C ool * non ^. = <: 

twelve bits in length? dlso ' c ^rect ^Le-error hursts uo to 

data*?* \r^JT\o { \^%[T T " ' " "»» * ^ ^ 

however, thae the ^ ' suLe^uUv V'-i' r ™ ' Su °™"' 

of this exception are 4: successfully the first tHe. The causes 

I. servo Error: this execution is Handle^ W ,s 

«™1"LT«™„™^" '5"/' ln cha »«•• ™. 

sioerea a catastrophic exception an the controller <rtll abort, 
for a rcatch header A"" ■ «««h.. the track tvlce 

seek back to the target locatio and retV . If a header "Jm* ^ 
tound the block will be spared, Header stil L ^can not he 

^ot^^^^^la^rrer <Z S ", K " ^ 

succ^c,-,,! r-a.a-^ 4„ ' . - tinfes j[ a total of 17) reads ■. t* , 

sui-l-sslIU read is encountered Hnrfno >-m „ , '■ - ' 

"111 save the ,alid data. " "the end t hV ".'XT"" 

had reads J or t... then the block U cr.n'fVr* -V -e Z 
nuciDer 13 between 2 and 111 then C-e 'at. -, ( n " ° 

but the controller goes bac£ "to "the tarce Moc<c""m ' 
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MISCELLANEOUS 



Parking: 



To guard against any 'mishaps when power, is shut off to Widget, there is a 
d^ frafrer'a t^Tl^ ""j! ^ heSdS ° ff the »• of he^ 

'fortunately it is os^'^r ^r^'r ^ ^ ^ " ' Par ' <iPV - 
uses of the Vr^o w V P<*r.<ing to synchronize with periodic 

hZt I, , ! \ £he * ost » "using, a mild form of thrashing Srought 

; . ■ " 1e , G '^tant seeking needed to move th* *eads be-ve-n ,I r -. 

iSe kid [ ?or V d °: e d t . C ° mpr - lse ^ ^ " park is 3 seconds and that 



^rm'Sween : 



I°J^m C head - an " ""rings from tpo many short seeks ' this causes 



S- 1 f*Test: 



'^hen the controller comes at, from being reset tt oerforms t^ e Following 
selftest tunctions: 1 



1 



/ 



2 



Q0^ 



Register Test 

Write and veri f y one ' s and zero'* to all registers; halt if 
failure - 
Stack, Test 

r3- Rarest PUSh/P ° P ' * C . aX1/r * tu ^ capabilities; halt if failure 

Write ones and zeros to all ram locations; don't allow ProFii e 
or System commands if failure. 
4 . Eprora Test 

Check external eprom banks D a|nd 1 for check bvte; don'' allow 

i lS 0T S ^ stem commands if failure. 
'J. Motor S oeed 

Check time from indent to index; don't allow =>roFile" or "vs:^ 
commands if failure. - ' 

*> • Track ~ount ' * ' 



Seek to track Jl and read a War, I- no heeader -ouV 
--ormat r-cal and count tracks; ion': ill 5W >rv'^ or * 
commands i e failure.. • « 
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BASIC SERVO FUNCTIONS 

Widget servo control functions are handled by a 28 microorocessor. The 

Z8 handles all I/O operations, timing ■■ operations and communication with a 

host controller. Control functions to che Z8 Servo Controller are made 
chrough che serial I/O. : ■• 

The following commands for cne Widget ' servo are: 

A. tiOME - no c decented, .heads off data zones located at :ne inner stop. 
3. RECAL - decented at one of two positions. 

1. FORMAT REGAL: 32, -0, +3 tracks from HOME use only during data 
format ting. 

2. RECAL: 72, -o, ^3 tracks from HOME use to initialize home posi- 
tion arcer power on or following an access or any other error. 

C. SEEK - coarse track. positioning of data head to any desired track 
location. 

3. TRACK FOLLOWING - heads are decented on a specific track iocacion and 
the device is ready for ano/ther command. 



OFFSET - controlled microscepping of fine position system during 
TRACK FOLLOWING (two modes). 

1. COMMAND OFFSET direction-: and amount of offset is soecified to 
che servo; v . ■ : 



Im, * 

* 



AUTO OFFSET - command allows the servo to automatically move off 
track by the amount indicated by che embedded servo signal on the 
data surface (disk). 

STATUS - command can read servo status, 

DIAGNOSTIC - not implemented. " 



3 m- 



See Table 1 for the actual command description. .With the oresenf » JB - 
mand structure a SEEK COMMAND can be -augmented vitn an' OFFSET JOMMAND . 
:?on completion of a seek, the offset command sic is testae co -ecer-ir.e 
*■ ~ in or: sec -ill occur following a iesK. ■,. eicner auto dt :omaana jf f set 



or cne communication function requires a specific orotocol b-we-n 
che servo Z3 processor and the exceraal controller. 

Servo concroi and communicacion are described in CHART E. This char^ 
"iiluscracas che basic sequencing and concroi operations. 'Chare I^does 
riot ixluscraca che servo error handling or command/ o rococol handling 
JS?" 1 ™ 8, £rr ° r handlin 8 13 described in Section IV and illustratec bv 

III. Z8 SERVO PROTOCOL i 

The prococol between che 23 SERVO microcomputer and che CONTROLLER is 
basea on rive I/O lines. Two of che I/O lines are serial input '. co ZS 
servo :rom concroller; serial output (from Zo servo to control!-*-- j . 
scream between che ZS. servo and concroller is 6 bic ACS 1 1 wich no paricv 
bit (cne nrch byte or the command scring concains cneck sura Dv Ce use for 
error eneexmg). There are chree additional oucouc lines becween cne Z3 
servo used as concroi lines co Che concroller. Combining che cwo serial 
I/O lines and che chree unidirectional port lines, generaces che bases o? 
che prococol becween che Z8 servo and :concroller . The imporcanc ope-a-" 
cions oecween che ZS servo and concroller are: 

1. Send commands co Z3 servo. 1 

2. Read Z3 servo status. 
Check validity of all four command bytes.: 
I/O timing signals becween /the Z8 servo and controller. 

5. Z3 servo reset. 

Sequencing the Z8 servo controller, is an. important process following a 
Power Jp (Power On Reset). or if the. controller should issue a Z3 Servo 
Reset at any time. After a 'ZS Servo Reset is . inhibited the ZS I/O ports 
and internal register are initialized.; This calces approximacaly 75 msec 
atcer the ZS bervo Reset is inhibited. The protocol baud rate is auto- 
matically set to 19. 2KB and then che system is parsed at HOME oosicion 
and oiO READY is sec active. *** IMPORTANT*** . If che desired' baud -ace 
neeus co oe increased co 37.6K3; **af cer a Z3 oervo Reset is -e 
time cms can oe cone"**, 0*ce set c^ 5 7 . orC3 ■ cne csamunicacton raT^"-*- 
mains ac o/.orCi until' a 23 Servo Reset , occur s .. Setting 57.oK3 is acnievec 
as rollows: i. .' : 

L. Z3 Servo "Power On or: Controller" ReSeV ' .' 

^"""™* • ■ 

^ , r • ..... i - ■ 

■*aic :or SIO Ready 
3. Send a READ STATUS CCMMaKD as follows: 



3 
4 



3YTE i * 3 00 



During Seek mode (velocity control only)' access time-out. If a Se-.< 
runction .exceeds 150 msec Chen an access time-out occurs. 

During Settling mode (following a ! Recal, Seek, or Offset;- if there <s 
excessive On Track pulses (3 crossings) indicating excessive bead 
aocion a Settling error check villi occur. 

During a command transmission if a communication error occurs (check 
sum error) 

During a command tansraission if a' invalid command is sent. 



■man 



IS 'SERVO COMMAND SYTci 
TABLE 1 
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BYT- 1: COMMAND BYTE < D I FCNT.H ) 
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read * t a * u s 


c omm an d 



c t i on 



Tm oitt2 < 51 2) 



n i oi t 



25*) 



1 (FORWARD: toward the spindle) 
9 (.REVERSE: away from the spinal 9 > 

1 - C 5i 2 tracks to go) 
9 (not set) 

1 ( 256 tracks ' to qo) 
9 (not sy&t) 



BYTE 2: D I FF BYTE < D I FCNTL ) 

•y . ! 

command BYTE 2 contains th* LOW ORDER ' DIFFERENCE COUNT 



■ o r a seek 
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! 86 
: 35 
: 34 
; 83 
1 32 
I Bl 
! B9 



•bij:7= 
-bi t6= 
-Oi t5= 

•OI t4aa 
■D I t o=s 

•bi t2= 
•b i 1 1 = 
•bi t9 = 



1 28 

64 

32 

1 6 

8 

4 

*• 

1 



tracks 
tracks 
tr ack s 
tracks 
tr acK s 
tracks 
tracks 
tr ack 
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BYTE 5: CHECKSUM BYTE CCXSUM) 



CB? 36 35 84 S3 B2',bY'*90] ".'.V 

results o* th« |P»««,Ttt»a CHECKSUM 8YTS d.riu«d at , 
i -T- r - i ~~-^~-- 57ii -- .-^^ 

f +; iS det,ned *« the* add! t, on etcvWE 

■■BYTE) is deemed »« the c omo l | me n t ' o?^Yn V" BYTE . i-a> 

^* SERVO STATUS 1 m*s .,310 ROY, SERVO $r.> TFcWJo EPRPF*. mus - - „ - 
tul,OW,n? ^na.t.on, , n order to ,,r,d the !, f 1 1/™' COMMANDS : 

'SERVO STATUS 
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it ; v: 

c 

Widget is Apple's in-house name -for the latest in a line o-f 

Winchester hard disks. This current version is available with 10.1 
MB o-f storage < -formatted >. 

Widget has been designed as a complete, self-contained 

intelligent subsystem. The purpose o-f this document is to explain in 

detail how this subsystem behaves within the complete system 
environment. 



t * - ..<*» . 
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App 1 e_Prof i 1 e_I n t erf ace 



A more complete description of 
be -found in the document " EXTERNAL 
PIPPIN HARDWARE " by Dick Wool ley and 
1981 . 



the Apple/Profile inter-face may 
REFERENCE SPECIFICATION <E.R.S> 
Wol-fgang Dirks, dated April 16, 



There are 5 control lines to/-from the Apple ProFile Inter-face Card: 

1 . Par i ty 

This line is 1 bit o-f odd parity < even parity across the 
cable >. The Inter-face Card is responsible -for monitoring 
this signal: the controller calculates parity only when it 
sends a word across the busj the controller does not check 
parity when a word is sent -from the host, instead the parity 
bit is is generated once more on the controller side of the 
bus and then routed back to the host. 

2. CMD < Command/Attention: Asserted by Host, Active high ) 
This signal is one o-f two handshake signals across the 
inter-face bus. Keep in mind that even though the host and 
controller are two autonomous machines, the host is always 
considered the master and the controller the slave < in this 
con-figuration ). When the host wishes to initiate a trans-fer 
to the controller it must -first check i -f BSY < discussed 
below ) is active. I -f BSY is active then the Host must wait < 
hope-fully it will set a DeadMan timer and catch a "sick" 
controller ) until BSY is no longer active. 

3. BSY < Busy: Asserted by Controller, Active High ) 

This signal is the dual «o+ CMD, in other words this is the 
signal with which the controller can hold o-f-f the host for an 
inde-finate period o-f time while it is "BUSY" per-forming some 
task. 



4. STRB < Strobe: Asserted by the Host, Active High ) 

Strobe is used to signal to the controller/host pair that 
data is val id on the bus. 

5. R/W < Read/Writes asserted by the Host, Write is Active Low 

> 

This signal is used by the Host to indicate to the- control 1 er 
which direction data is to be going during a transmission. 
Read is used to direct data out of the controller into the 
host and the oppos i te • cond i t i on is true for Write. 
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Pro-file Communication Protoco l: 

The -following is an explanation o-f the protocol that is used 
to provide communication between the host and the controller: 

< Some explanation o-f the symbols that I am using is probably 
called -for at this point. ) 

'<,>' : The bracket symbols mean that the in-formation inclosed 
within them are mandi tory. 

' [ , 3 ' : The square bracket symbols mean that the in-formation 
inclosed is optional. 

' I ' : The vertical bar symbols is used to indicate an alternative 
or "OR" condition. For example, A I B can be thought o-f as "Either 
A OR B" . 

' : : = ' : This symbols is used to indicate a de-f i n i t i on or 
equivalence. 

'<,>" : Curly brackets are used to denote comments. 
' + ' : The plus sign is as an addition symbol. 

'NULL' : This key word indicates the empty set, or in some cases, 
the fact that the -function whose value is NULL can be ignored. An 
ex amp 1 e is: 

Argle-Bargle : := < NULL > 

Essentially you can forget that Argle_Bargle exists for this 
con tex t . 
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PROF I LE_COMMANDS 

These commands are currently by the SOS driver. Widget is 
designed to be backwards compatible with the current ProFile driver, 
and to that end there exists the three ProFile system commands: 
Read , Wr i te , and Wr i te_^er i -f y . 

Pro-file Commands: 



Opcode De-f i n i t i on 



Read Logical Block 
*#1 Write Logical Block 

*02 Wr i te/Ver i -fy Logical Block 



The three Pro-file commands behave in exactly the same -fashion as 
do the corresponding instructions on ProFile, with one small 
exception: the Read Logical block command does not include 
i n-f ormat i on concerning Retry count or Sparing threshold { however, 
because o-f a side e-f-fect in the way that the Host/Controller 
inter-face was designed, the Host may write as many command bytes to 
the controller as it chooses. The controller will only decode the 
■first 4. >. The -form o-f each command is: 

<%m I *01 I *02> < 3 Bytes o-f Logical Block Address > 

There are two 'special/ logical addresses de-fined in the ProFile 
protocol, namely *FFFFFF < -1 } and SFFFFFE < -2 >. Logical address 
< -1 > returns as it's value Device_ID C as explained under the 
Widget Diagnostic commands > and Logical address < -2 > returns as 
it's value Widget's spare table structure in it's raw -form. It 
should be noted that if at any time Widge > t can not pass it's sel-f 
test that it will re-fuse to communicate via logical commands C both 
ProFile and System type commands >. Widget will respond to 
Diagnostic commands at all times, however. 

The rest o-f the commands available on Widget are a complete 
departure -from the ProFile way o-f doing things. The new -form o-f 
command i s : 

< < Command_Byte > 

< I nstruc t i on_By te > 

[ 1 nstruc t i on_Parame ter_Str i ng ] 

< CheckByte > ) 

Command_Byte : := < CommandType_N i bbl e + CommandLength_N i bbl e > 
CommandType_Ni bbl e : := < D i agnost i c_Command I System_Command > 
D i agnost i c_Command : : = < $1.3 > 
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System_Command : := < *20 > 

CommandLength_N i bbl e : Count of all bytes in the command string 
NOT including the first one. This length is used only to calculate 
the checkbyte, and not to parse the command, there-fore there is a 
large variety o-f commands that perform exactly the same function but 
differ in format in that their lengths are not the same. 

IF System_Command 

THEN I nstruc t i on_Byte : := <Sys_Read I Sys_Write I 
Sys_U)rUer> 

IF D i agnost i c_Command 

THEN Instruct i on_Byte : := < 

Read_ID I 

Read_Con trol 1 er_ Status I 

Read_Servo_Status I 

Send_Servo_Command I 

Send_Seek I 

Sen d_Re store I 

Set_Recovery I 

Soft_Reset I 

Send_Park I 

D i ag_Read I 

D i ag_ReadHeader I 

D i ag_Wr i te I 

Store_Map I 

Re ad_Sp ar eTab 1 e I 

Wr i te_Spar eTabl e I 

Format_Track I 

I n i t i al i ze_Spar eTabl e I 

Read_Abor t_Stat I 

Reset_Servo I 

Scan > 

I nstruc t i on_Parame ter_Str i ng :;= < This string is instruction 
dependent, and will be formally specified at the same time as the 
individual instructions. ) 

CheckByte : := C This byte is the ones-complement of the sum, in 
MO.D-254 arithmetic, of all the bytes including the Command_Byte >. 
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D I A6N0ST I C_COMMANDS 

Widget"'* "personality", or the manner in which it behaves, can be 
thought oHF as having two distinct parts* 1) that portion that is 
dictated by the hardware and 2) that portion that is controlled by 
the -firmware. As trite as that last statement may seem on the 
surface, the -fact remains that the part of Widget that is the 
hardware is not easily molded to adapt to different environments. 
The same is true, but not quite in the same manner, for the firmware 
- the code is locked in a ROM of some sort and costs a lot to 
change. How then can Widget's "personality" be changed < on-the-fly 
> to "adapt" to a new environment? The answer in this case to 
architect the firmware in a layered fashion: build the intelligence 
required to run Widget in it's normal operating mode -from a pool of 
discrete, primitive functions; these primitive functions in most 
cases have only one particular task that they are capable of 
completing. The implication of this architecture is that with very 
little effort these same primitive functions are availble to the 
host system, and thus make Widget a little "Schizoid". Such luxuries 
do not come without their hidden costs, however. For one thing, the 
Widget controller is slightly more expensive to manufacture <. a cost 
that I believe pales in the sight of the added test/diagnostic 
capabilities > because of the additional code space required for all 
the bells and whistles, and another is that someone must now develop 
Host software to emulate the controller firmware design of choice. 

The purpose of the rest of this section on Diagnostic Commands is 
to aquaint the casual /not-so-casual designer of Host software as to 
how to make the best use of Widget's multiple personality 
capab i 1 i ties. 
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Read_ID : := < S00 > 

Instruct i on_Parameter_Str i ng : := NULL 

This diagnostic command requires Widget to deliver to the host some 
device speci-fic i n-f ormat i on . The structural layout o-f the data 
returned is: 



STRUCTURE I den t i t i y_B 1 oc k 



{ this identity block is de -fined by the data structures contained 
within it; you will note, however, that a comment is given 
explaining the type o-f structure -for a given element and range o-f 
bytes (. i -f the entire structure is thought o-f as a linear array o-f 
bytes > that include the structure. An example is NameString C -first 
element to be de-fined below > which is a 13-character asc i i string, 
and is located in bytes $0 thru *C o-f. the returned block. 

NameStr i ng : := < 

10MB_Name I 
20MB_Name I 

40MB_Name <. 13 By tes/*00 :*0C ; Asc i i String >> 

10MB_Name : := < 'Widget-10 ' > 

20MB_Name : := < 'Widget-20 ' > 

40MB_Name : := < 'Widge.t-40 ' > 

DeviceType : : = <Dev i ce .W i dge t +W i dge t . S i z e+W i dqe t .Type C 3 Bytes/*0 

i*0F >> 

Dev i ce .Wi dge t : : = <*0001 C 2 By tes/*0D :*0E >> 

Widget. Size : := <Size_10 I Size_20 I Size_40 { 1 Nibble, Byte *0F/ 

i ts 7:4 >> 

Si ze_10 : := <*00> 
Si ze_20 : := <*10> 
Si ze_40 : := <*20> 
Widqet.Type : := <System i Diagnostic < 1 Nibble, Byte *0F/bits 3: 

>> 

System : := <*00> ; This re-fers to the type o-f -firmware that i 

i mbedded i n 

W i dge t . 

System -firmware will not allow the host to Format, or 
I n i t i al i ze_SpareTabl e ; Diagnostic -firmware will. 

Diagnostic : := <*01> 

Fi rmware_Revi si on : := << 2 By tes/*10 :*1 1 >> 

Capacity : := <Cap_10 I Cap_20 I Cap_40 < 3 By tes/*l 2 :*1 4 >> 
Cap__10 : := <*004C00> 
Cap_20 : := <*009800> 
Cap_40 : := <*013000> 

Bytes_Per_Bl ock : := < *0214 < 2 Bytes/*15:16 >> 



J 
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Cyl_10 : := <$0202> 
Cyl_20 : := <*02i2f2> 
Cxi _40 ::= <*0404> 

Number _Of_He ads : := <*02 C 1 Byte/*!? >> 

Niirnber_Of_Sectors : :•= < Sctr_lJ0f I Sc tr_20 I Sctr 40 C 1 Byte/*1A }> 
Sctr_10 : := <*13> 
Sctr_20 : ;= <*26> 
Sctr__40 : := <*26> 

Number_0-f_Possi bl e_Spare_Locat i ons s := <*00004C < 3 By tes/*l B D >> 
Number_0-f_Spared_Bl ocks : := << 3 By tes/*l E :S20 ; range 0. .*4B >> 
Number_0-f_Bad_B1 ocks : := << 3 Bytes/*21 :*23; range 0..*4B >> 
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Read_Control 1 er_Status : : = <*£fl> 

Every time an operation completes C either successfully or 
exceptionally > Widget will return what I refer to as 
Standard_Status , thus allowing the Host system an opportunity to 
change it's flow of execution based on state of the Status, 
Normally, this Standard_Status is all that is necessary to ensure 
continuous operation. In the exceptional case, or when the Host 
system is emulating the controller's functions, additional 
information concerning the state of Widget is mandatory: without it 
the Host simply could not make an optimum choice in deciding a 
course of action. 

Con trol 1 er_Status is then a means for the Host system to 
interrogate Widget further. Each Status C with the exception of 
Abor t„Status , which is a seperate command and is d i scussed 1 ater in 
this document > belongs to a homogeneous data structure: namely a 
four byte quantity containing a bit map representing the various 
exceptional conditions C active high > that is available as the 
first four bytes read from the controller upon completion of the 
current command. 

There are eight status' available to the Host system. The Host 
requests a specific status by setting I nstruc t i on_Parame ter_Str i ng 
to the value corresponding to the status needed. 

IF < I nstruc t i on_Byte = Read_Con trol 1 er_Status > 
THEN I nstruc t i on_Parame ter_Str i ng : := < 

Standard_Status I 
Last_Logi cal_Bl ock I 
Cur r en t_Seek_Address I 
Curren t_Cy 1 i nder I 
Internal _Status I 
State_Reg i sters I 
Excep t i on_Reg i ster s I 
Last_5eek_Address > 

The four byte response to each of the above status requests is of 
the form: 



Result : := < Bytetf Bytel Byte2 ByteS > 
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Standard Status : := 



ByteJBf : := < 



Bytei ::= < 



Byte2 : := < 



Bi t7 
Bi t<6 
Bi t5 
Bi t4 
Bi t3 
Bi t2 
Bi tl 
Bi tJ0f 



Other than *S5 response -from Host 
Write Buffer OverFlow 
(. not used > 
C not used > 
Read error 

No matching header found 
Unrecoverable servo error 
Operation Failed > 



( not used ) 

Spare Table OverFlow 

5 or 1 ess spare blocKs available 

< not used > 

Controller SelfTest -failure 
SpareTable has been updated 
Seek to wrong track occured 
Controller aborted last operation > 



Bit7: First status response since power-on reset 
Bi t6: Last Log i cal _B1 ock_Number was out of range 
b i t5 :J0f < not used > > 



Bi 


t7 


Bi 


t6 


Bi 


t5 


Bi 


t4 


Bi 


t3 


Bi 


\2 


Bi 


tl 


Bi 


tss 



Byte3 : := < 

Bit?: Read Error detected by ECC circuitry 
Bit6: Read Error detected by CRC circuitry 
Bi t5s Header Timeout on last read 
Bi t4x { not used > 

Bit3:0 : number of unsuccessful retries { out of IS! > for last 
read 
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Last_L.og i cal _B1 ock : := < $01 > 
Byte0 : := < *00 > 

Bytel : != < < Most Significant Byte of Log i cal _B1 ock_Number > > 
Byte2 : := < { Middle Byte o-f Log i cal _B1 ock_Number > > 

Byte3 s := < < Least Significant Byte o-f Log i cal _B1 ock_Number > 

> 



Current Seek Address : := < *02 > 



ByteJ0f 
Bytel 
Byte2 
Byte3 



= < Most , S i gn i -f i can t Cylinder Address > 

= < Least Significant Cylinder Address > 

= < Head Address > 

= < Sector Address > 



Curren t_Cyl i nder : := < $03 > 

< The Curren t_Cyl i nder differs from the Curren t_Seek_Addr ess in 
that it is perfectly reasonable for the Servo to have placed the 
heads on another track under certain circumstances; for example, the 
dr i ye may have been bumped > 

Byte0 : : = < Most Significant Cylinder address > 

Bytel s := < Least Significant Cylinder address > 

Byte2 : := < Most Significant Cylinder of current seek address > 

8yte3 : := < Least Significant Cylinder of current seek address 

> 
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Internal Status : := < *04 > 



Byte0 : := < < Registers Excpt_Status > 



Recovery ON > 



t7s Recovery < active high — > 

t6: Spare almost -ful 1 

t5: Buf-fer structure is contaminated 

t4: Power reset has Just occured 

t3: Current Standard Status is non-zero 
t2:l : < not used := > 

t0: Set i-f controller LED is lit > 



Bytei : : = < { Register: DiskStatus > 

Bit7s On__Track < heads are position where they 
should be > 

Bit<£: Read a Header a-fter Recal 

Bit5: current operation is a WRITE operation 

Bit4: Heads are parked 

Bit3: Do sequential search o-f Logical Block 
look-ahead structure 

Bi t2: Last commad was a multi block command 
Bi tl : Seek_comp 1 e te 

Bi t0: Servo o-f-fset C auto > i s on > 



Byte2 : := < C Register: BI kStatus > 

This byte o-f status is valid ONLY a-fter a ProF i 1 e/System 
command. I-f the byte is read a-fter a Diagnostic command it 
will contain in-formation concerning the last 
non-D i agnost i c command. 

Bi t7: SeekNeeded C a seek was needed to arrive at 
the current block > 

Bit6: Head_Change_Needed i like Bit?, but Head 

change instead o-f seek > 

Bi t5:2 *00 < not used > 

Bitl: Current Block is a Bad Block 

Bit0: Current Block is a Spare Block > 



Byte3 : := < *00 { not used > > 



F i rm_2 . Sc r i p t 



Widget Firmware Specification 



Page 13 



State_Regi sters : := < *05 > 



Bytetf 



:= < *00 C not used > > 



Bytel : := < C Register: Se 1 -fTst_Resu 1 t J 



t7 
t6 
t5 
t4 
t3 
t2 
tl 
tJff 



Ram_Fa i 1 ure 
Eprom_Fa i 1 ure 
D i sk_Speed_Fa i 1 ure 
Servo_Fa i 1 ur e 
Sec tor_Coun t„Fa i 1 ure 
State_Mach i ne_Fa i 1 ure 
Read_Ur i te__Fa i 1 ure 
No_Spare_Tabl e_Found > 



Byte2 '.'.= <(. Register: Port2 ) 

Bit7s Disk Read/Write direction set to Read 

Bit6: Servo is able to accept a command C SioRdy > 

Bit5: MSell C MSe 1 and 1 determine the memory 

source and destination > 

Bi t4: Msel0 

Bit3: BSY 

Bit2: CMD 

B i 1 1 : Ecc Error 

BitJ0fs State machine is running > 



ByteS ! := < < Register: Con trol 1 er_Status_Por t > 
B i 1 7 : CrcError < active low > 

{ this bit is valid ONLY when the 
controller state machine is NOT in reset, 
which should be every time that this bit is 
, read by the host. There-fore, i f this status 
"bit indicates a CrcError, then something 
has croaked. The normal way -for the host to 
check i f a Crc or Ecc error has occured is 
to examine Status: Excep t i on_Reg i sters 
which are di cussed below. > 



Bit6: Wr i te_Not_yal i d C active low ) 

< as in CrcError, this bit is valid only 
when the state machine is NOT in reset. The 
information expressed by this bit is 
converted into a type of ServoError , which 
is -found in Status: Excep t i on_Reg i sters . > 

,. Bj.t5 : ServoReady 

'~"J3h"'tA i Serv ©Error 

i the servo status bits listed above are 
-further explained in Appendix A: Servo 
Processor Documentation. Essentially the 
two bits combine to form four possible 
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servo states? the normal condition fs 
ServoReady AND < NOT ServoError ). > 
Bit3:0 Current controller state-machine state. 

i as in CrcError and Wr i te_Not_Val id, these 
status bits are valid only when the state 
machine is NOT in reset, and should read 
$00 any other time. > 

On the surface it appears that this byte is of limited use -for non 
real- time situations. It is, however, invaluable in trying to 
decide i i the Servo Processor is healthy, wealthy, and wise. It also 
provides a means -for diagnosing a sick state machine. 
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Excep t i on_Reg i ster s : := < %Q6 > 

Byte0 : := < < Register: RdStat > 

Bit?: Read error occured on last read attempt 
Bi t6s Servo Error while reading 

Bi t5: At least one successful read in last read 
attempt < this means that valid data is residing in 
Buffer2 > 

Bit4: No matching header was -found during last read 
attempt 

Bit3: CrcError OR EccError occured during last read 
attemp t 

Bi t2:0 *J0fJBf { not used } > 

< a read attempt is de-Fined as being the sequence of events normally 
associated with reading a single block o-f data. In the case where 
the -first read o-f a block was invalid -for some reason, AND Recovery 
is active, then the controller will automatically retry ? times: 10 
tries total . For example, if the -first read was inval id because o-f a 
CrcError, but the second thru tenth reads are all correct then the 
status bits that will be active are Bit5, and Bit3. Correct and 
valid data will be both in the normal Read bu-f-fer and in Buffer2. > 



Byte 1 : := < 

Bit?: Error detected by 
Bit6: Error detected by 
Bit5: Header timeout 
B i t4 : { noy used := 3 } 
B i 1 3 : : Number o-f bad 
attempt > 



ECC 
CRC 



c i rcu i try 
c i rcu i try 



retries during last read 



For the above example, this status byte will contain the value *C1 



Byte2 : := < 



C Register: UlrStat > 

Bit7: Write error occured on last write 
Bit6: Servo Error while writing 
Bit5: At least one success-ful write 
wr i te at temp t 

Bit4: No matching header -found during 
at temp t 
Bi 1 3 :&-*## 



at t emp t 
dur i ng 1 ast 
1 ast wr i te 



< not used > 



{ A write attempt is much the same 
are several events that can keep the 
successfully - and can be detected 
write. If Recovery is active then 
the write buffer to Buffer2 and then 



as a read attempt in that there 
controller from writing a block 
at the time of the attempted 
the controller will first copy 
retry > 



Byte3 : := < Number of bad retries during last write attempt > 



mm 
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Read_Servo_Status s := < *02 > 

I nstruc t i on_Par ame ter_Str i ng : := < #..8 > 

This status command is used to interrogate the Servo Processor in 
much the same way that Read_Con trol 1 er_Status is used. In -fact, the 
form of the result is the same four byte bit-mapped quantity. 

This command is of particular value to a diagnostician that is 
interested in ' p i ck i ng-abou t ' with the servo processor without 
dismantling Widget as a subsystem. Refer to Appendix A: Servo 
Processor Documentation for a complete description of the various 
status' available and their resulting bit descriptions. 



Send_Servo_Command : := < *03 > 

I nstruc t i on_Par ame ter_Str i ng : := < Bytetf Bytel Byte2 Byte3 > 

Normally, the Host will allow the controller to manipulate the servo 
processor in order to perform useful < or maybe not so useful! > 
work. For example, let's suppose that the Host system wishes to 
move the disk drive heads from one track to another. Under normal 
operating conditions the preferred way to perform this task is to 
use the Send_Seek command i explained below >. However, the Host has 
the capability to bypass the controller and direct the servo 
processor. Indeed, the Host can issue the servo command, to position 
the heads < via the Send_Servo_Command > so that the seek is 
completly transparent to the con trol 1 er . The implication of this 
command is that the Host can gain even more control of the system if 
i t so chooses . 

A more complete description of the Servo Commands can be read in 
Appendix As Servo Processor Documentation. 

Byte# : := < S_Command + S_Direction + H i _Magn i tude > 
S_Command : := < 

Offset 
D i agnost i c 
DataRecal 
FormatRecal 
;•• :-y , Ac c ess 

Access_0f f se t 
Home 

Offset : := < *ij0f > 

The Offset command allows the Host to microstep the heads 
in either a positive or negative direction from the center 
of the track. The Widget Firmware does not make use of 
this feature! I have instead left this to a more specific 
data recovery program that is run by the Host. The value 
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and direction of the microstep are sent to the Servo 
Processor in Byte2. 

Diagnostic : := < *2J0 < this command is not implemented in the 
Servo > > 

DataRecal : := < *40 > 

DataRecal C and also FormatRecal > is used as a 'Get the 
servo in a known state' command, and is usually sent by 
the controller during initialization time or whenever the 
servo is not "Ready'. This command places the heads over 
the -first data track closest to the inside diameter of the 
disk, within a tolerance o-f 3 tracks. The accepted method 
■for making certain that the heads are over a known track 
■following a DataRecal is to read a header and use the 
track information located in the header to establish the 
1 ocat i on . 

FormatRecal s := < *?0 > 

This command is identical to the DataRecal command except 
■for the track that the heads end up over upon completion: 
about 36 tracks closer to the inside diameter o-f the disk. 
Unlike the DataRecal command, however, the disk surface in 
this area is not likely correctly store information 
written there. This command then is used to supply an 
absolute reference point when formating the drive. 

Access : := < *80 > 

I use the term 'access' and 'seek' interchangeably within 
the context of this document. The servo Access command is 
used to position the heads a relative distance from their 
current position. The Servo Processor has no knowledge 
concerning absolute position and it i s up to the 
controller < real or emulated > to supply the relative 
distance. This information is passed along in ByteJEf and 
Bytel. 

Access_Of f se t : := < *?# > 

The difference between an Access and an Ac c ess_Clf f se t is 
that the assumption is made that heads will position 
themselves within a 'tolerable' distance of the center of 
the track with an Access command, while no such assumption 
is made with an Access_pf f se t command. There is some 
information written on each track of the disk 'under' the 
index mark. This information is used by the servo 
processor to 'calculate' the center of the track { data 
center } and position the heads accordingly. Because the 
servo must wait for the index to arrive under the heads 
before it can read this information there is an implied 
latency of about 1 revolution t currently 19.4 msec > 
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attached to each Access_Of f se t . Normally, the Widget 
controller will use the Access commarrd -for all reads, and 
the Access_Qf f se t command -for all writes. 

Home : := < $C0 > 

When the heads are 'Homed' they are sent completely off 
the data surface and held in position very near the inside 
diameter crash stop. 



S_Di recti on : := < Positive I Negative > 

Positive : s= < $04 C move the heads toward the outside 
diameter > > 

Negative : := < $00 i move the heads toward the inside 
d i ame ter > > 



Hi_Magnitude s := < 0..3 < move the heads a multiple of 256 
tracks > > 



Bytel s := < Low_Magn i tude : := 0..25S > 

H i _Mag i n i tude + Low_Mag i n i tude , and S_Di recti on establish the 
relative distance the heads must move to arrive at the target 
track. 



Byte2 : ;= < Of f se t_D i r ec t i on + Auto Of f se t_Sw i tch + Of f se t_Magn i tude 

> 

This command byte, when used with the Offset command, establishes 
the degree and direction of m i cr ostepp i ng . 

Of f se t_D i rec t i on : := < Positive I Negative > 

Positive : := < $80 C offset towards outside diameter 

> > 

Negative : := < $00 (. offset towards inside diameter > 

> 

Au to_Of f se t_Sw i tch : := < ON I OFF > 

ON : := < $40 <. turn automatic track centering on 
without an access command > > OFF : := < $00 { do not 
auto track center on this command > > 
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O-f 4 se t_Magi n i tude 



: := < Z. .32 > 



Byte3 



: := < Baud_Rate + Power On Reset > 



Baud_Rate : := < l?.5k_Baud I 57.6k_Baud > 

The servo 'comes up' at 19. 5k baud because o-f the 
test equipment used on it be-fore it is integrated 
into a system. Once it is running with a controller, 
however, it is run continuosly at 57.4k baud. This 
parameter is also a bit misleading in that once the 
servo has been told to go to 57.6k it will -forever 
more ignore this parameters in other words it is 
impossible to go -from the higher baud rate to the 
lower without reseting the servo processor. 

l?.5k_Baud : := < %m > 
57.6_Baud : := < *80 > 

Power_On_Rese t : := < *4# > 

This is one o-f three way to reset the servo 
processor (. such variety! }. The other two ares 
1) Power switch, and 2> have the controller pull 
on the servo reset line. Out o-f all three 
methods, choice two is the most pre-ferable in 
that the controller will completely initialize 
all the drive parameters related to the servo as 
well Ss automatically go to the higher baud 
rate . 
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Send_Seek : := < *04 > 

Instruct i on_Parameter_Str i ng : s= < HiCyl LoCyl Head Sector > 

Widget's Send_Seek command allows the Host system to place the 
heads over any track on the disk. The value of the seek address 
sent in the parameter string is used read/write a block of data 
using the diagnostic commands -for those functions. For example, 
for the Host to read Cylinder 1, Head 0, Sector 18 a 
Seek_Command would be issued for that combination of cylinder, 
head, and sector C $0001 00 12 > followed by a Diag_Read £ 
explained below >. 
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Send Restore : 5= < *05 > 



Restore_Data : := < $40 > 
Restor e_Format : := < $70 > 

The Send_Restore command is used by the host to initialize the 
servo processor and to put the heads in a known location. This 
command is the same as performing a Data/Format Recal except 
that the controller updates it's internal state to account -for 
the new servo position { as opposed to using the 
Send_Sergo_Command , which is transparent to the controller >. 
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Set_Recovery : := < %86 > 

I nstruc t i on_Parame ter_Str i ng : := < ON I OFF > 

ON : := < *01 > 
OFF : s= < S00 > 

To the best o-f my ability I have attempted to make the 
exception handling characteristics o-f Widget a binary set: 
either Widget handles everything, or the Host system does. The 
command Set_Recovery is the Host's link with this all or 
nothing world in that it is through this instruction that the 
Host can gain control o-f the media. When Widget comes up after 
being reset it assumes control and sets Recovery to be ON. The 
Host system must overtly change this state £ via Set_Recovery > 
i-f it wishes to emulate a di-f-ferent exception handling 
criteria. Once Recovery is OFF, the controller will always -fail 
in an operation i-f an exception occurs: the Host system MUST 
assume responsibility -for ALL error handling. 
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So-f t_Reset : := < *07 > 

Instruct i on_Par ame ter_Str i ng : := < NULL > 

This commands instructs the Widget -firmware to restart it's 

flow o-f execution at it's initialization point. The results 

should be the same < -from a so-ftware po i n t-of-v i ew > as a 
power-rese t . 
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Send_Park : := < $08 > 

I nstruct i on_Parameter_Str i ng : := < NULL > 

When the Host issues a Send_Park command to the con trol 1 er the 
results are that that the heads are moved off the data surface 
and held very near the inside diameter crash stop. The 
difference between this command and the Send_Servo_Command : 
Home is that Home is performed "open-loop" wi th~"the crach stop 
as it's reference point, while Send_Park is an access command 
to a specific track. The net result Ts a -fairly hefty saving of 
time: the access command can be an order of magnitude quicker 
than Home/Recal . 
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Diag_Read : := < %%? > 

I nstruc t i on_Parame ter_Str i ng : := < NULL > 

The Diag_Read command is used to read the block on the disk 
pointed to by the last seek address. This instruction is valid 
for states that the controller might be in: it is advised that 
a Send_Seek command precede the Read. The -form of the returned 
data is exactly the same as that of ProFile_Read or a Sys_Read 
in that 4 bytes o-f Standar d_Status precede the block o-f data. 



Di ag_ReadHeader : := < *0A > 

I nstruc t i on_Parame ter_Str i ng : := < Sector < *0..*12 > > 

When the heads are positioned over an unknown location, or when 
it is suspected that a block's header is shot, it is time to 
use the D i ag_ReadHeader command. This instruction allows the 
host to "suck-up' both whatever information is residing in the 
block's header -field as well as the data -from that block. The 
-form o-f the result is: 

Resu It : := ( 

< Standard_Status/*00:*03 > 

< Header/*04:*0? > 

< Gap/*0A:*0F > 

< Sync/*10:*1 1 > 

< Data/*12. . > ) 

Standard_Status : s= < < as de-fined above > > 

Header : := < HiCyl LoCyl HdSc t -HiCyl -LoCyl -HdSct > 

HiCyl : :=* < 1 Byte, Most significant cylinder address 

> 

LoCyl : := < 1 Byte, Least significant cylinder 
address > 

HdSct s ;= < 1 Byte, bits?:6 are head address, bits5:0 
are sector address > 

-HiCyl : := < Ones-complement of HiCyl > 

-LoCyl : s= < Ones-complement of LoCyl > 

-HdSct : : = < Ones-complement of hdSct > 



f 
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Gap : := < 5 bytes o-f %BZ > 
Sync : := < *0lJ0T0 > 
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Diag_Write : := < *0B > 

I nstruc t i on_Parame ter_Str i ng : := < MULL > 

This instruction allows the host to write a block o-f data to 
the location on disk pointed to by the last seek address. 
Diag_Write is valid -for all states that the controller may wind 
up in, but it is recommended that a Send_Seek command precede 
the write command to ensure that the correct block will be 
wr i t ten . 1 



* 



I 
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Store_Map : := < *0C > 

I nstruc t i on_Par ame ter_Str i ng : := < NULL > 

The Store_Map command is to be used by the Host to logically 
re- i n ter 1 eave Widget, Widget will be used on a number of target 
hosts, each o4 which would like to optimize the performance C 
sequential } o-f the disk drive. This optomization can occur in 
one o-f two ways; 1) either seperate lines are set up in 
manufacturing to initialize Widgets specifically for each 
target host or 2> we can manufacture a single Widget unit and 
have the Host initialize the drive for it's specific 
requ i remen ts . 

Included in the SpareTable structure is a data structure called 
the I n terLeave_Map . This map is used as another level of 
logical addressing during the calculation of a cylinder, head, 
and sector address from a given logical block address. 
Specifically stated, once a sector address has been determinied 
it is used as an index into the I n terLeave_Map and a new sector 
address is generated i the I n terLeave_Map is an array with the 
same number of entries as there are sectors, and each entry 
must be unique and valued within the range of legal sector 
values > . 

It is extremely important that the host system proceed with 
caution when changing the Map. A remapping of the elements 
within the SpareTabl e is REQUIRED with every change to the Map 
<. this is because as the sectors are logically remapped the 
defects that stay with a physical address move around relative 
to a logical block's number >. For this reason I suggest that 
all changes to the map be done using the Wr i te_SpareTabl e 
command in conjunction with a remapping of all the spare/bad 
blocks. 

This command is externally executed (. by the host > as a write 
command. The first Number_Of _Sec tors worth of data in the 
buffer are assumed to be the new map. 
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Read_SpareTabl e : := < *0D > 

I nstruc t i on_Parame ter_Str i ng : := < NULL > 

Reading < and writing > Widget's spare table is an absolute must -for 
diagnostic purposes, and i f the Host wishes to emulate the 
controller. The result of this instruction is identical to 
performing a ProFile_Read -from block *FFFFFE and has the -forms 

Resu 1 t s ;= < 

< Standard_Status/*00i*03 C as de-fined above > > 

< Fence/*04:*07 > 

< RunNumber/*08 :*0B > 

< FormatJDff set/*0C > 

< Format_I n terLeave/*0D > 

< HeadPtr_Array/*0E:*8D > 

< SpareCount/*8E > 

< BadBI ockCount/*8F > 

< Bi tMap/*8A:*?3 > 

< Heap/*?4:*1C3 > 

< InterLeave_Map/*lC4:*lD7 > 

< Checksum/*! D8 s*l D? > 

< Fence/*1DA:*1DD > > 



Fence s != < < *F0 > < *78 > < *3C > < *1E > ) 

R'-T.iNumber : := < 32-bit interger > 

The RunNumber is incremented each time the spare table is 
writen to the disk. Because two copies are kept on the 
disk, the RunNumber is used to decide which is the more 
recent o-f the two should both copies o-f the table not be 
updated . 

Format_0-f-f se t : := < $00 . .NumberD-f Sec tor s > 

Format_0-f f se t is the number o-f physical sectors there are 
-from index mark until logical sector 0. 

Format_I n terLeave s i= < *00..*06 > 

This number is the interleave -factor -for this disk and is 
used in calculating where each o-f the logical sectors are 
in terms o-f actual physical sectors. 

HeadPtr_Array : := < ARRAY C . . 1 27 1 of HeadPtr > 

HeadPtr : ;= < Nil + Ptr > 
Nil : := < *00 I *80 > 

If a HeadPtr is Nil, then there is no 
linkecl-list structure in the heap corresponding 
to the current loqical block number. 

Ptr : := < *00 . .*7F > 
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A Ptr is a seven bit data structure that 
'points' to a spec i -f i c location within the Heap 

C i -f the Heap can be though o-f as a linear array 

' o-f bytes, the a Ptr is used to index into that 

array >. To arrive at the actual index value 

within the Heap, the Ptr must -first be 
multiplied by -four. 

When a disk is -formatted and -fresh data is being written to it, 
each logical block is asigned the -first available physical 
block on the disk. There-fore you would expect that 
Logi cal Bl ock< 8 ) would occupy Phys i cal Bl ock < >, L( 1 > — > 
P< 1 ) , etc. There are instances, however, when a block o-f data 
must be relocated to another space on the disk that does not 
-follow the original progression { -for example, the original 
space was de-fective >. In order to 'find" these relocated 
blocks in the -future a record must be kept as to where all 
these relocated blocks have been put. This record takes the 
■form o-f 128 linked lists having the -form HeadPtrCn) — > 
L i nkedL i st < n ) , where n := 0..127. The algorithm -for deciding 
whether or not a Log i cal Bl ock has been relocated is to extract 
bits 16:10 -from the Log i cal Bl ockNumber and use it as an index 
into the HeadPtr_Arr ay . I -f the HeadPtr associated with this 
index value is Nil then LogicalBlock has not been relocated 
else use HeadPtr. Ptr to search the linked list corresponding to 
this HeadPtr value. Now to decide i -f the LogicalBlock has been 
relocated a test must be made as the linked list is traversed 
by comparing the Log i cal Bl ockNumber ' s bits 9:8 to the current 
list element's token value. If they match then LogicalBlock has 
been relocated and it's new position is a multiple o-f the list 
element's position in the Heap. 

SpareCount : := < *0JBT..*4C > 
BadBl ockCount : := < *00..*4C > 

BitMap : := < ARRAY [ 0..*4B ] o-f Bits > 

The bit map is used to keep a record o-f which spare blocks 
are occupied, and their locations on the disk. 

Heap s := < ARRAY C #..*4B 3 o-f ListElement > 

Li stEl emen t : := < 

< N i 1 +Used+Useabl e+Spr_Type+Data_Type > 

< Token > 

< Ptr > ) 

Nil : := < *80 { IF Nil THEN End_0-f _Cha i n > > 

Used : := < *40 > 

Useabl e s := < *2# > 

SprType : := < Spare i BadBl ock > 



t 
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Spare : i= < *U0f > 
BadBI ock : :=» < *0j0T > 
Data_Type : := < Data I SpareTable > 
Data : s= < *02 > 
SpareTable : := < *08 > 

Token : := < Bits?:0 o-f the Log i cal Bl ockNumber > 



InterLeave_Map : := < ARRAY IB . .NbrSc tr s] OF Z . .NbrSc tr s > 



Checksum : := < the 
■first -fence to the 



sum o-f all bytes in the spare table -from the 
end o-f the heap, in MOD-65536 arithmetic > 
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Wr i te_Spare_Tabl e : := < *0E > 

Instruct ion_Parameter__String : := < < *FJEf > < *78 > < *3C > < *1E > > 

This command allows the Host to '-force' a new spare table on 
the controller, and" is executed just like any o-f the other 

write commands < the data in this case MUST con-form to the 

structure presented in Read_SpareTabl e >. The data sent to the 

controller is written to the two spare table locations on the 
di sk . 
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Format_Track : := < *0F > 

I nstruc t i on__Parameter_Str i ng : := < 

< Format_0-f f set > 

< Format_I n terLeave > 

< Password > 

Format_Of f se t : := < %%% . .Number_Of _Sec tors > 

This parameter dictates which sector < beginning with 
secto?rJ0r - the first physical sector after index mark > 
will be logical sector S3 -for that track. 

Format_I n terLeave : := < *#0 . ,%&6 i interleave factor > > 

Password : := < < *F0 > < *78 > < *3C > < *1E > ) 

The format command is used tos 

1. Operate on the track that is currently beneath the 
heads - this impl i es that the Host had best perform a 
Send__Seek command prior to formatting a track. 

2. AC erase the entire track - this implies that all 
data stored on this track has acheived Nirvana and 
are living happlily ever after in the great bit 
bucket in the sky. 

3. New headers will be 1 ayed down on EVERY sector of 
the track . 
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I n i t i al i ze_SpareTabl e : := < *1# > 
I nstruc t i on_Parame ter_Str i ng : := < 

< Format__Of f set > 

< Format_I n terLeave > 

< Password > 

Format_Of f se t s := < *00 . .Number _Of_Sec tors > 

Format_InterLeave : s= < $80 . .*&6 C interleave factor > > 

Password : := < < %FSS > < *78 > < *3C > < *1E > > 

This command form the Host instructs the controller to 'wipe 

the slate clean" as far as the SpareTable is concerned. The 

initialized table is written to disk. 



F i rm_4 . Scr i p t 



Widget Firmware Specification 



Page 35 



Read_Abor t_Status : s= < $11 > 

I nstruc t i on_Par ame ter__Str i ng : ! = < NULL > 

Read_Abor t_Status will return valid data only AFTER the 
controller has aborted C identified by 

Standard_Status.Bytel.Bit0 >. The form of the result is a 
sixteen byte string, and the contents are the contents of the 
controller's registers at the time of the abort - with the 
exception of bytes $0E and *0F, which constitute the return 
address of the procedure that called the Abort routine. Because 
all of the information that can be derived from this request 
from is extremely firmware dependent an appendix < Appendix C: 
Abort_Status Variables > has been created that hopefully will 
be updated with each firmware release. 
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Reset_Servo : := < $12 > 

I nstruct i on_Parame ter_Str i ng : := < NULL > 

Reset_Servo allows the host to initialize the servo processor 
without having to power the device down. The controller will 
automatically reset the Servo, check for valid initial 
conditions and per-form a Data_Recal . 
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Scan : := < $13 > 

Instructi on_Parame ter_Str i ng : := < NULL > 

The Scan command causes the Widget to read all blocks that are 
with the range o-f blocks set aside -for user data blocks. If any 
o-f these blocks are bad then the block will either be relocated 
< i f the data can be recovered > or marked as bad and relocated 
on the next write to that block. The SpareTable can be examined 
be-fore and after a Scan command -find the locations o-f all bad 
bl ocks . 



F i rm_4 . Scr j p t 



Widget Firmware Specification 



Page 38 



SY ST EM_C OMM AN D S 

System_Commands have been implemented -For essentially two reasons! 

1. I -felt that it was important -for Widget to add one more check on 
the CMD/BSY handshakes namely the addition of a checkbyte -following 
the command string. 

2. In order to increase the performance o-f the system without 
modifying the hardware it was critical to introduce another level o-f 
parallelism into the Host/Controller inter-face. Most < 60'/. or 
greater > o-f the reads -for a specific block on the disk are -followed 
by a read -for the logically sequential block. In -fact, in the 
extreme case o-f Lisa, this percentage is almost 100'/.. There-fore I 
have suppressed the command decoding -for all but the -first block 
read < over a small range ). The implementation, then, -for this 
added parallelism is to send an additional parameter with the < 
■first > LogicalBlock indicating the number o-f blocks to be read. 

This implementation holds -for Reads and Writes, .but not -for 
Wr i teUer i f i es . I have taken the liberty o-f assuming C hope-fully 
correctly > that Wr i te*v>er i f i es do not exhibit the same 
characteristic behaviour as the other two types o-f commands, and 
that they are -fairly long commands to begin with. The trade-o-f-f then 
was one o-f saving code space <. a Sys_WrUer is the same routine as a 
Pro_WrUer, but with command checkbyting > vs. adding a third 
multiblock -function with limited performance increases. 

The protocol -for System commands is slightly different then that of 
Profile commands. In the case of a Read command, each block of data 
is transfered to the host when it received by the controller: there 
is NO bufferin-g of disk blocks on Widget at this time. The transfer 
looks just like other read-style transfers in that Standard_Status 
is sent with the data block and the data block is the same length C 
532 bytes >. Instead, however, of responding with the basic 
'Controller is ready for command' response when the Host sets CMD < 
after storing the data block > the controller will respond with a 
'Controller ready to get next block' response. 
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Sys_Read : := < $00 > 

Instruction_Parameter_String : := < < Block_Count > < LogicalBlock > 

> 

B1ock_Count : := < *01..*13 > 

This parameter is the number of blocks to be read that 
■follow sequentially from Log i cal Bl ock . It i s assumed that 
one block C LogicalBlock > will be read, making the 
Block_Count the number o-f blocks -following the -first one 
that is to be read, also. 

LogicalBlock : := < L_10MB I L_20MB I L_40MB > 

L_10MB ::= < *000000 . .*004BFF > 

L_20MB : s= < *000000. .*0097FF > 

L_40MB s:= < $000000 . .*01 2FFF > 
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Sys_Wr i te : := < *01 > 

Instruct i on_Parame ter_Str i ng : := < < Block_Count > < Log i cal Bl ock > 

) 

B1ocK_Count : := < *01..*13 > 

Logical Block : := < L_10MB I L_20MB I L_40MB > 
L_10MB s:= < *000000 . .*004BFF > 
L_20MB : := < $000000 . .*00 9 7FF > 
L 40MB ::= < $000000 . .*01 2FFF > 



Sys_WrUer : := < $02 > 

I nstruc t i on_Par ame ter_Str i ng : := < LogicalBlock > 

Logical Block : : = < L_10MB I L_20MB I L_40MB > 

L_10MB : := < $000000 .. $004BFF > 

L_20MB : s= < $000000. .$0097FF > 

L_40MB < $000000. . $012FFF > 
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HANDSHAKE PROTOCOL 

Both Widget and ProFile share the same Host inter-face scheme, and 
there-fore a lot in common when it comes to trying to communicate 
with the Host system. ProFile's protocol is documented in "ProFile 
Communication Protocol'', and a follow-up document titled "The 
Extended ProFile Protocol' written by Karl Young is available -for 
more de ta i 1 . 

The actual sequence o-f events can be portayed as -follows: 

Protocol_Sequence : := < 

< In i t i al_HandShake > 

< Command_DownLoad > 

< Response_HandShake > 

I Data_Rece i ved.JHandShake ] 

< Fi nal_HandShake > ) 

In i t i al_HandShake : : = 

1. Host asserts CMD, sets data direction to read 

2. Controller asynchronously responds by: 

a. Writing %Z\ to the Host 

b. Asserting BSY 

3. li the Host recognizes the controller response, it will 
respond by: 

a. Writing a *55 to the controller 

b. Otherwise it will write a *AA 

c. In either case the Host will de-assert CMD. 

4. The controller will respond to the Host by: 

a. In either case C whether the Host responded with a 
$55 or *AA or anything else > the controller will 
eventually end up waitinq for the next instance o-f 

.CMD. 

b. I -f the response was a *55 then the controller will 
be a 'captive' audience, anxiously awaiting 
instructions -from .the Host as to what to do next. 

c. Otherwise, the controller will Abort, and leave 
Standard Status saying so in it's bu-f-fer where the 
host dan- read it. The state o-f the command sequence 
-for the controller then becomes Initial _HandShake , 
and the Host should read do it's best to read the 
Standard Status as soon as it notices that the 
handshake sequence has been changed. The execption to 
this 'Otherwise' is when the response -from the Host 
is a FreeProcess response < explained below >. 

Command Down Load : : = 
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1. The Host writes a variable length string of hex bytes 
to the controller. The address o-f where these bytes are 
sent is set up by the controller in the I n i t i al _HandShake 
phase. The length o-f the hex string is up to the Host, but 
is intended to be the length o-f a command string < indeed, 
the string o-f bytes is supposed to be a command string! >. 
The controller knows to increment it's address counter C 
remember, it is responsible for loading the string into 
it's memory > by a -falling edge o-f STROBE -from the 
inter-face card. 

Response_HandShake : := 

1. The Host asserts CMD 

2. The controller responds asynchronously by -first reading 
it's buffer in the locations that it set aside -for the 
Host to per-form it's command download, doing what is 
necessary to decode the command i i.e., validating the 
checkbyte, making certain that the command was o-f the 
right type, and decoding the command >. It then writes a 
response byte to the Host which has the value o-f < 
I nstruc t i on_By te + 2 ). 

3. The controller asserts BSY 

4. i look at 3. -for I n i t i a 1 _Han dSh ak e > 

5. If the controller receives a *55 then it will continue 
executing the command, otherwise it will Abort and return to 
In i t i al _HandShake . 

Data_Rece i ved_HandShake : := 

1. If the controller is expecting data C as is the case 
for a write command > then in the Response_HandShake it 
will de-assert BSY and wait for the next occurance of CMD. 

2. When the Host "sees' BSY become de-asserted it will 
then write as much data as it pleases (. like the command 
download, the controller dictates the address of the data 
while the Host dictates the length >. 

3. The Host the asserts CMD 

4. The controller responds asynchronously to the Host by 
writing a $06 to the Host. 

5. The controller then asserts BSY 
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6. Assuming the Host accepts the response from the 
controller, it will respond by writing *55 back to the 
controller and then de-asserting CMD. 

7. The controller will then continue executing the 
command. 

Fi nal ._HandShake : : = 

1. When the controller finishes with the execution of the 
instruction, 

it will put the latest Standard_Status in a location in 
it's buffer 

where it will be accessible to the Host ( as well as 
any data that 

might be a result of the command execution >. 

2. The controller then de-asserts BSY 

3. The Host detects that BSY has been de-asserted and then 
reads from the controller as many bytes as it wishes C in 
much the same fashion as it does when writing a command 
string to the controller: the controller points to the 
data and the Host moves it >. 



There is (at least > one implication to this protocol: the Host is 
capable of tying up 180'/. of the control 1 er's resources if it so 
chooses. This is because the control ler has no way of knowing when 
the Host has finished reading/writing from/to it's data buffer. 
There needs, therefore, to be a mechanism for the Host to let the 
controller know that it has freed up the controller's resources. 
This mechanism C for lack of a better name > is called the 
FreeProcess. The Host communicates the FreeProcess to the control le 
in either of two ways: 1) the ProFile way, and 2) the Widget way. 

Pr oF i 1 e_FreePr ocess : : = 

1, The Host downloads a commands of < $F0 > to the 
con tr ol 1 er . 

2. The controller decodes the command and enters 
FreeProcess. 



W i dge t_FreeProcess : := 

1. During the I n i t i a 1 _HandShak e i when the controller is 
attempting to let the Host know that it is ready -For a new 
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command > the Host responds to the $01 with a *69. 

2. The controller responds to the reception o-f a *69 
instead o-f *55 by entering FreeProcess. All -further 
handshaking is terminated. 



* 
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COMMAND SUMMARY 

Pr oF i 1 e_Comman ds : 

ProFile_Read : != < <*00> < 3 bytes Log i cal Bl ock > ) 
ProFi 1 e_Ulr i te : := < <*01> < 3 bytes Logical Block > ) 
ProF i 1 e_WrMer i f y s := < <*02> < 3 bytes LogicalBlock > ) 

Di agnost i c_Commandss 

Read_lD : := ( <*12> <*00> <*ED> > ? 
Read_Controll er_Status : := < <*13> <*0i > < Status > < CheckByte > 

> 

Read__Servo_Status : := < <*13> <*02> < Status > < CheckByte > ) 
Send_Servo_Command : := < <*16> <*03> < 4 command bytes > < 
CheckByte > ) 

Send_Seek : := < <*16> <*04> < 4 bytes cyl /head/sec tor > < 
CheckByte > > 

Send_Restore : := ( <*13> <*05> < Data/Format Recal > < CheckByte > 

) 

Set_Recouery s s= < <*13> <*0<6> < tin/Q-f-f > < CheckByte > ) 
So-ft_Reset : := < <*12> <*07> <*£6> ) 
Send_Park : := < <*12> <*08> <*E5> ) 
Diag_Read : := < <*12> <*0?> <*E4> ) 

Di ag_ReadHeader : := < <*13> <*0A> < Sector > < CheckByte > ) 
Diag_Write : := < <*12> <*0B> <*E2> ) 
Store_Map : := < <*12> <*0C> < *Ei > > 
Read_SpareTabl e : := ( <*12> <*0D> <*E0> ) 

Wr i te_SpareTab1 e : := < <*14> <*0E> < Password > < CheckByte > ) 
Format_Track : := < <*13> <*0F> 

<0-f -f set XInterLeaveXPassWordXCheckByte) ) 
I n i t i al i ze_SpareTabl e : : = 

< <*16> <*10> < O-f-fset > < InterLeave> < Password > < 
CheckByte > > 

Read_Abor t_Stat : := < <*12> <*i 1 > <*DC> ) 
Reset_Servo : := ( <*12> <*12> <*DB> > 
Scan : := < <*12> <*13> <*DA> ) 

System Commands: 

Sys_Read : := 

< <*26> <*00> < BlKCnt > <r : 3 bytes LogicalBlock > < 
CheckByte > > " 

Sys_Wr i te : : = 

< <*26>- <*0i> < BlkCnt > < 3 bytes LoqicalBlock > < 
CheckByte > ) 



Sys_WrYeri*y : := < <*25> <*02> < 3 bytes LogicalBlock > < 
CheckByte > ) 
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Password : := < $F0 *78 *3C *1E > 
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Exception Handling: 

Widget has been designed to run -fault -free -for most of it's 
operating time. This means that almost every single time that a 
request is made o-f the controller it will be performed flawlessly. 
However, there are some exceptional cases - most fall into the 
category of extreme errors- where the controller must attempt to 
correct a problem. The most likely to occur is either when the drive 
is externally "bumped" and the heads are forced off track, or flaky 
block is read C crc/ecc error >. 



SERVO EXCEPTIONS 

It is possible for the Servo Processor to detect that the heads 
have gone off track. When this occurs the Servo will attempt to put 
the heads back on track transparently to the controller. There are 
three outcomes to this exception: 

1. The Servo will put the heads back on the correct track and 
all will be well with the world. 

2. The Servo will mistakenly put the heads on a track that is 
close to the target, track. In this case the controller will 
detect a header mismatch the next time it reads a block on the 
d i sk and will i ssue a seek to correct the position error. 

3. The Servo will raise ServoError C a gross misalignment 
detected > and drop ServoReady in which case the controller 
will have no choice but to issue a DataRecal to clear the 
ServoError, then issue a seek to get back to the target track. 
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READ/WRITE EXCEPTIONS 

There are occasions when the a spot on the disk surface becomes 
unuseable, or -for some reason causes the data stored in that area to 
change. To handle this type of exception Widget is equiped with 2 
error detecting devices and 1 error correcting device i although Ecc 
is both error detecting and error correcting >. Widget uses a 
sixteen-bit crc polynomial < CRC-16 > to detect all single-burst 
errors less than sixteen bits in length, almost all single-burst 
errors o-f sixteen bits, and most single-burst errors greater than 
sixteen bits in length. A 48-bit ecc polynomial is also used that 
has error detecting properties similar to that o-f the crc 
polynomial, except that it handles burst o-f up to 48 bits. It can 
also correct single-error bursts up to twelve bits in length. 

When a block read, i -f the -first read is successful < no errors > 
then the data is transfered to the Host, thus completing it's 
command. Suppose, however, that the block is not read successfully 
the first time. The causes of this exception are 4: 

1. Servo Error: this execption is handled by leaving the read 
routine and getting in touch with the Servo Processor to see if 
things can be straightened out. Once the controller is 
convinced that the Servo is well and that the heads are 
positioned where thye should be, it retries the read. 

2. The state machine indicates that it is in the wrong ending 
state. This is considered a catastrophic exception an the 
controller will abort. 

3. The state machine indicates that a matching header was not 
found. Before making this decision the state machine searches 
the track twice for a match header. To handle this exception 
the controller reads a header from the track that the heads are 
currently positioned over and tries to determine if the heads 
are positioned correctly. If they are, then it is assumed that 
target block's header is faulty and the track will be spared. 
If no header can be read from the track it can be determined if 
the heads are positioned correctly or if all headers on the 
track are shot. In this case the controller will issue a data 
recal' and seek back to the target location and retry. I -f a 
header still can not be found the block will be spared. 

4. The state machine indicates that a crc or ecc error has 
occured. The controller will automatically retry 9 times C a 
total of I S3 reads >. If a successful read is encountered during 
this retry session the controller will save the valid data. At 
the end of all the retries, if the number of bad reads was 2 or 
less then the block is transfered to the Host. If the number is 
between 2 and IB then the data is still returned to the Host, 
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but the controller goes back to the target block and performs a 
Writeyerify with the valid data; if the block fails the verify 
then it is spared. If the number of bad reads is 10 then the 
ecc correction algorithm is applied to the result of the last 
retry. If the data is correctable then it is returned to the 
Host; the target block is then write verified with the valid 
data and if it fails it is spared. If the data is 
uncorrectable, then undefined data is returned to the Host C if 
it chooses to read it > and Standard_Status indicates that the 
operation failed. The target block is then declared a BadBlock 
< a form of spare >. 

BadBlocks have the property that when they are read the 
controller will attempt to extract the data from the target 
block and performing exactly the same steps as i n a normal read 
in an attempt to recover the data. When they are written to, 
the controller performs a write verify to the target block. If 
the block passes the ver i f yu then it is no longer a BadBlock, 
otherwise it is spared. 

SpareBlocks have the property that they are 'relocated' 
1 ogi cal bl ocks. In other words, SpareBlocks are blocks on the 
disk that are transparent to the Host and were set aside for 
the explicit purpose of relocating faulty blocks. There are 76 
such SpareBlocks on each Widget, spaced 256 blocks apart on a 
10MB drive, 512 blocks apart on a 20MB drive, and 1024 blocks 
apart on the 40MB drive. When I decided upon this sparing 
algorithm I chose a trade-off between overall performance and 
data secur i ty . 

When a block is spared, it is relocated to the nearest available 
spare block so that the time to get to it is minimized. This 
works only as long as spared blocks are more or less uniform 
over the entire disk surface. On 5 the other hand, if the ideal 
case were to be implemented < the controller keeping track of 
which blocks on the disk were unused and relocating to the 
nearest one > the space needed to contain the data structure 
that kept track of the algporithm would be enormous. The 
decision to keep the structure contained inside of one data 
block C 512 bytes > led to the 'checker-board' algorithm that 
has been implemented on Widget. 
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MISCELLANEOUS 

Parkings 

To guard against any mishaps when power is shut off to Widget, 
there is a mechanism in the -firmware that takes the heads off 
the data area of the disk after a period of idleness. This 
mechanism is known as 'parking'. Unfortunately, it is possible 
■for parking to synchronize with periodic uses o-f the drive by 
the Host, causing a mild -form o-f thrashing brought about by the 
constant seeking needed to move the heads between the park 
position and the target position. It was determined 

empirically on ProFile that a good compromise delay time to 
park is 3 seconds and that time hold -for Widget. 

Arm_Sweep ; 

To protect the head-arm bearings -from too many short seeks i 
this causes a possible migration o-f lubrication away -from the 
sur-faces that are meant to be lubricated > the arm is swept the 
complete width o-f the disk data surface every 2048 seeks. 

Sel -f_Test s 

When the controller comes up -from being reset it per -forms the 
following selftest functions: 

1 . Regi ster Test 

Write and verify one's and zero'z to all registers; 
hal t if fail ure 

2. Stack Test 

Check push/pop, call/return capabilities; halt if 
f a i lure 

3. Ram Test 

Write ones and zeros to all ram locations; don't 
allow ProFile or System commands if failure. 

4. Eprom Test 

Check external eprom banks SS and 1 for check byte; 
don't allow ProFile or System commands if failure. 

5. Motor Speed 

Check time from index to index; don't allow ProFile 
or System commands if failure. 

6. Track Count 

Seek from the format recal position to track 0. This 
test fails if the servo is unable to complete this 
task . 

7. Spare Table 
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Find both spare tables and write verify them; don't 
allow ProFile or System commands i f -failure. 

8. Read/Wr i te Test 

Widget performs a read/write test on a track not used 
■for data. I-f a failure occurs on all blocks of that 
track then the controller assumes that either the 
disk or the read/write channel is unusable. 
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APPENDIX C: Abort. Status Variables 



There are occasions when the Widget controller will detect that 
something is radically wrong with the Widget subsystem, i.e., the 
ram on-board the controller goes on vacation, or the state machine 
gives up the ghost, etc. In one of these cases the controller will 
'abort' it's current instruction 4nd return control to the Host, 
hope-fully with enough information that the Host can make an 
intelligent decision concerning the state o-f the Widget. 

The Host can read in some information concerning the abort that the 
controller took by read Last_Abor t_Status . This command returns a 
result that is 20 bytes long: 4 bytes o-f Standar d_Status followed by 
14 bytes of abort status. The contents of the 16 byte result is 
dependent upon the abort taken, and is determined by examining the 
contents of the 15th and 16th bytes which are a pointer into the 
firmware where the abort occured. 

In the following list the contents of bytes 15 and 16 are indicated 
{ as a hexadecimal 16-bit integer, just as you would read them from 
the buffer; byte 15 most significant... >, with a brief description 
of th ereason why the abort was taken as well as any comments 
concerning other bytes of immediate interest included within the 
Abort Status structure. 



*02EA: Illegal interface response, or Host Nak 

Byte09: Response Byte received from Host -=.» 
*03B8: Illegal Ram_Bank select 

Byte00: Bank number of attempted select 
$0487: Format Error: Illegal State_Mach i ne State 

Byte0A: State of State_Mach i ne at time of failure 
*04CB: Illegal Bank_Switch: Either call or return 

Byte00: Bank number of attempted bank select 
$0513: Illegal Interrupt or Dead_Man_T i meou t 

Byte0A:0B : Address of routine at time of timeout 
$1101: Format Error: Error while writing sector 

Byte09: Error Status from FormatBlock 
*11EA: Command CheckByte Error 

$1203: ProFile or System command attempted while SelfTest error 
$1217: Illegal Interface instruction 

$1310: Unrecoverable Servo Error while reading '* v.$v 
$13E8: Sparing attempted on non-existent spared bl oc'il' 
*1513: Sparing attempted while spare table full 
*158D: Deletion attempted of non-existent bad block 
$16B4: Illegal exception instruction 
$191?: Unrecoverable Servo Error wh i 1 e ,wr i*t i nq 
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*lBJ0fls Servo Status request sent as Servo Command 
*1B56: Restore Error: Non-Recal parameter 

Byte00: Illegal parameter sent 
*1BAB: Store_Map Error: Parameter larger then the number of sectors 

Byte0A: Illegal parameter sent 
$1BD2: Illegal password sent -for Wr i te_Spare__Tabl e command 
*1C15: Illegal password sent -for Format command 
*1C24: Illegal -format parameters 

ByteJ09: Offset parameter 

Byte#A: interleave paramter 
*1C78: Illegal password sent -for Initial i ze_Spare__Tabl e command 
*1CFF: Zero block count sent for MultiBlock transfer 
$1E4A: Write Error: Illegal Statejiach i ne state 

Byte#A: State_Mach i ne state at time o-f error 
*1F2F: Read Error: Illegal State_Mach i ne state 

ByteiJA: State_Mach i ne state at time of error 
*2#21 : ReadHeader Error: Illegal State_Mach i ne state 

Byte0A: State_Mach i ne state at time of error 
*21F7s Request for illegal logical block 

BytetfC: High byte of requested logical block 

Byte0C: Middle byte of requested logical block 

Byte0C: Low byte of requested logical block 
*2370: Search for SpareTable failed 

$249,3: No SpareTable structure found in SpareTable 
S24B3: UpDate of SpareTable failed 
$2522: Illegal SpareCount instruction 

Byte#9: Value of illegal instruction 
*265E: Unrecoverable Servo Error while performing overlapped seek 
*26B8: Unrecoverable Servo Error while seeking 
*2?EjET: Servo Error after Servo Reset « 

ByteJSA: Value of controller status port at time of error 
*2AlJ0: Servo Communication error after Servo Reset 
*2D13s Scan attempted without SpareTable 



WIDGET SERVO FUNCTIONAL OBJECTIVE 



BASIC SERVO FUNCTIONS 

Widget servo control functions are handled by a Z8 microprocessor. The 
Z8 handles all I/O operations, timing operations and communication with a 
host controller. Control functions to the Z8 Servo Controller are made 
through the serial I/O. 

The following commands for the Widget servo are: 

A. HOME - not detented, heads off data zones located at the inner stop. 

B. RECAL - detented at one of two positions. 

1. FORMAT RECAL: 32, -0, +3 tracks from HOME use only during data 
formatting. 

2. RECAL: 72, -0, +3 tracks from HOME use to initialize home posi- 
tion after power on or following an access or any other error. 

C. SEEK - coarse track positioning of data head to any desired track 
location. 

D. TRACK FOLLOWING - heads are detented on a specific track location and 
the device is ready for another command. 

E. OFFSET - controlled microstepping of fine position system during 
TRACK FOLLOWING (two modes). 

1. COMMAND OFFSET - direction and amount of offset is specified to 
the servo. 

2. AUTO OFFSET - command allows the servo to automatically move off 
track by the amount indicated by the embedded servo signal on the 
data surface (disk). 

F. STATUS - command can read servo status. 

G. DIAGNOSTIC - not implemented. 

See Table 1 for the actual command description. With the present com- 
mand structure a SEEK COMMAND can be augmented with an OFFSET COMMAND. 
Upon completion of a seek, the offset command bit is tested to determine 
if an offset will occur following a seek (either auto or command offset). 



w % When a SERVO ERROR occurs the Z8 SERVO will attempt to do a short RECAL 

(ERROR RECAL). Two attempts are made by the system to do the ERROR RECAL 
function. If either of the two RECAL operations terminate successfully 
the protocol status will be SERVO READY, SIO READY and SERVO ERROR. 
Should the ERROR RECAL fail then the system will complete the error 
recovery by a HOME function. 

The two OFFSET commands will be described. First COMMAND OFFSET is a pre- 
determined amount of microstepping of the fine position servo. Included 
in the OFF-SET BYTE (STATREG) bit B6=0 is a COMMAND OFFSET. Bit B7-1 is a 
forward offset step (toward the spindle); B7=0 is a reverse step. In the 
case bit B6=l the OFFSET command is AUTO OFFSET. 

AUTO OFFSET command normally occurs during a write operation. When the 
HDA was initially formated at the factory special encoded servo data was 
written on each track "near" the index zone. The reason for this follows: 



Normal coarse and fine position information for the position servos is 
derived from an optical signal relative to the actual data head-track, 
location. Over a period of time the relative position (optical signal) 
will not be aligned to the absolute head-track position by some unknown 
amount (less than 100 uln). This small change is important for reliabil- 
ity during the write operation. Write/Read reliability can be degraded 
due to this misalignment. The special disk encoded servo signal is avail- 
able to the fine position servo and will correct the difference between 
the relative position signal of the optics and the absolute head to track 
position under the data head only at index time. The correction signal 
can be held indefinitely or updated (if desired at each index time) or 
until a new OFFSET command or move command (SEEK or RECAL) occurs. 



II. COMMUNICATION FUNCTIONS 

The servo functions described in the previous section only occur when the 
servo Z8 microprocessor is in the communication state. Communication 
states occur immediately after a system reset, upon completing head set- 
ting after a recal, seek, offset, read servo status or set servo diag- 
nostic. A special communication state exists after a servo error has 
occurred. If + SIO READY is not active no communication can exist between 
the external controller and the servo Z8 processor. 

Servo commands are serial bits grouped as five separate bytes total. Re- 
fer to Table 1 parts I through V as the total communication string. First 
byte is the command byte (i.e. seek, read status, recal, etc.). Second 
byte is the Low order difference for a seek (i.e. Byte 2 = $0A is a ten 
track seek). Third byte is the offset byte (AUTO or COMMAND OFFSET and 
the magnitude/ direction for command offset). Fourth byte is the status 
and diagnostic byte (use for reading internal servo status or setting 
diagnostic commands). Byte five is the check sum byte used to check ver- 
ify that the first four bytes were correctly transmitted (communication 
error checking) . 



f Part of the communication function requires a specific protocol between 

the servo Z8 processor and the external controller. 

Servo control and communication are described in CHART I. This chart 
illustrates the basic sequencing and control operations. Chart I does 
not illustrate the servo error handling or command/protocol handling 
functions. Error handling is described in Section IV and illustrated by 
CHART II. 



III. Z8 SERVO PROTOCOL 

The protocol between the Z8 SERVO microcomputer and the CONTROLLER is 
based on five I/O lines. Two of the I/O lines are serial input (to Z8 . 
servo from controller) serial output (from Z8 servo to controller). Data 
stream between the Z8 servo and controller is 8 bit ACSII with no parity 
bit (the fifth byte of the command string contains check sum byte use for 
error checking). There are three additional output lines between the Z8 
servo used as control lines to the controller. Combining the two serial 
I/O lines and the three unidirectional port lines generates the bases of 
the protocol between the Z8 servo and controller. The important opera- 
tions between the Z8 servo and controller are: 



1. 


Send commands to Z8 servo. 




2. 


Read Z8 servo status. 




3. 


Check validity of all four 


command bytes. 


4. 


I/O timing signals between 


the Z8 servo and controller. 


5. 


Z8 servo reset. 





Sequencing the Z8 servo controller is an important process following a 
Power Up (Power On Reset) or if the controller should issue a Z8 Servo 
Reset at any time. After a Z8 Servo Reset is inhibited the Z8 I/O ports 
and internal register are initialized. This takes approximately 75 msec 
after the Z8 Servo Reset is inhibited. The protocol baud rate is auto- 
matically set to 19.2KB and then the system is parked at HOME position 
and SIO READY is set active. ***IMPORTANT*** . If the desired baud rate 
needs to be increased to 57.6KB; **after a Z8 Servo Reset is the ONLY 
time this can be done***. Once set to 57.6KB tne communication rate re- 
mains at 57.6KB until a Z8 Servo Reset occurs. Setting 57.6KB is achieved 
as follows: 

1. Z8 Servo "Power On _or Controller" Reset 

2. Wait for SIO Ready 

3. Send a READ STATUS COMMAND as follows: 

BYTE 1 = $ 00 

BYTE 2 = 5 00 

BYTE 3 = $ 00 

BYTE 4 = $ 87 



fm After the completion of transmitting the bytes, the Z8 Servo Controller 

chanzg.es to 57.6KB and will be waiting for the next transmitted command 
at 57.6KB. 

Before the controller transmits the command byte the controller must pole 
the SIO READY line from the Z8 servo to determine if it is active (+5 
volts). If the line is active then a command can be transmitted Co the 
Z8 servo. The program in the Z8 servo will determine what to do with the 
command bytes (depending upon the current status of the Z8 servo). After 
the command (five bytes long) has been transmitted to the Z8 servo, the 
program in the Z8 servo will determine if the command bytes (first four 
bytes) are in error by evaluating the check sum byte (fifth byte trans- 
mitted). See table Chart III and IV for the error handling. After the 
controller has transmitted the last serial string it must wait 250 usee 
then test for SERVO ERROR active (+5 volts). If SERVO ERROR is active the 
command was rejected (check sum error or invalid command). If the SERVO 
ERROR is set active 600^360 after the command is sent (and not 250 sec), 
this was a command reject. The SERVO ERROR must be cleared by READ 
STATUS COMMAND or RECAL COMMAND before transmitting another command. 
See CHART 1 for time diagram of the command sequence and I/O protocol. 

As long as SIO READY is active the controller can communicate with the Z8 
Servo Controller. If SERVO READY is not active the only command that will 
cause the Widget Servo to set SERVO READY active is a RECAL COMMAND (NOR- 
MAL or FORMAT) . Read Status will only clear SERVO ERROR. And all other 
commands will be rejected. " 

Next, if SERVO READY is active and SERVO ERROR is also active, SERVO 
ERROR can be cleared by: 

1. Any READ STATUS COMMAND. 

2. Any RECAL COMMAND. 

3. Any other commands will be rejected and maintain SERVO ERROR. 

If a SEEK COMMAND is transmitted with both SERVO READY and SERVO ERROR 
active the command will be rejected. 

It is important to check the status of all three status lines from the 
Z8 Servo. It is best to avoid sending a SEEK COMMAND with SERVO READY 
and SERVO ERROR active. 

Chart V parts A-I illustrate some of the serial communication commands 
and error conditions that can occur between the controller and Z8 SERVO. 



IV. ERROR HANDLING 

SERVO ERROR will be generated during the following conditions: 

1. During Recal mode (velocity control only) access time-out. If a Recal 
function exceeds 150 msec then an access timeout occurs. 



I 

2. During Seek mode (velocity control only) access time-out. If a Seek 
function .exceeds 150 msec then an access time-out occurs. 

3. During Settling mode (following a Recal, Seek, or Offset) if there is 
excessive On Track pulses (3 crossings) indicating excessive head 
motion a Settling error check will occur. 

4. During a command transmission if a communication error occurs (check 
sum error) . 

5. During a command tansmission if a invalid command is sent. 



APPENDIX A: 



I. The purpose of the FINE POSITION SERVO is to maintain detent or lock on 
a given data track. Any misregistrations of the head/arm due to windage, 
mechanical observed by the optics position signal are corrected by the 
close loop position servo. Misregistrations at the data head relative to 
the actual data track on the disk must be corrected by the AUTO OFFSET 
command. Figure I illustrates a block diagram of the Widget FINE POSI- 
TION SERVO. The amount of misregistration at the data track sensed after 
a AUTO OFFSET command are summed into the servo and the servo is automat- 
ically repositioned over the data track. 

II. The COARSE POSITION SERVO (SEEK) has the function of moving the data 
head arbitarily from a current track to any other arbitrary track loca- 
tion within the total' number of track locations between the inner to 
outer crash stops. When a command is transmitted to the Z8 Servo con- 
troller, the Z8 decodes and interprets the command into a servo function. 
If a SEEK command is sent to the Z8 Servo Controller a direction and 
number of tracks to move is also sent. The system starts its move to the 
new track location. When the arm has moved to its new location the Z8 
Servo Controller provides control and delay necessary to allow the data 
head and the FINE POSITION SERVO to come to rest immediately following a 
SEEK. This insures that motion in FINE POSITION SERVO and data head will 
be under control when the READ / WRITE channel begins operation. Reliabil- 
ity of "the data channel is assured with high margins. Figure I illustrates 
a block diagram of the Widget COARSE POSITION SERVO. 

The differences between the FINE POSITION SERVO and the COARSE POSITION 
SERVO is handled by the Z8 Servo Controller. The two servos share for 
the most part the same set of electronics. The Z8 Servo Controller and 
analog multiplexers switch between the signal paths. In general there 
are some circuits that are not shared because of their uniqueness for a 
particular servo. 
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I. BYTE 1: COMMAND BYTE ( DI FCNTH) 



command 
bi ts 



access 
bi ts 



B7 
B6 
B5 
B4 



B3 -X- not used 
B2 -access direction 
BI -hi di-f-f2 (512) 
BQ -hi di-f-fl (256) 



B7 


B6 


B5 


B4 


FUNCTIONS 




i 











access only 




1 





8 


1 


access with o-f-fset 




9 


1 








normal recal <to trk 


72) 





1 


1 


1 


•format recal < to trk 


32) 











1 


of-fse t-trk following 




1 


i 








home -send to ID stop 




9 





1 





diagnostic command 
















read status command 





access direction = 
hi d i -f -f 2 <512) 
hi di ii 1 (256) 



1 < FORWARD : toward the spindle) 

(REVERSE: away -from the spindle.) 

1 (512 tracks to go) 

(not set) 

1 ( 256 tracks to go) 
(not set) 



I I . BYTE 2 : D I FF BYTE ( DI FCNTL ) 

command BYTE 2 contains the LOW ORDER DIFFERENCE COUNT for a seek 



B7 


-bi 


t7= 


128 


tracks 


B6 


-bi 


t6= 


64 


tracks 


B5 


-bi 


t5= 


32 


tracks 


B4 


-bi 


t4= 


16 


tracks 


83 


-bi 


t3- 


8 


tracks 


32 


-bi 


t2= 


4 


tracks 


81 


-bi 


1 1 = 


2 


tracks 


80 


-bi 


t0= 


1 


track 



WIDGET SERVO FUNCTIONAL OBJECTIVE 



BASIC SERVO FUNCTIONS 

Widget servo control functions are handled by a Z8 microprocessor. The 
Z8 handles all I/O operations, timing operations and communication with a 
host controller. Control functions to the Z8 Servo Controller are made 
through the serial I/O. 

The following commands for the Widget servo are: 

A. HOME - not detented, heads off data zones located at the inner stop. 

B. RECAL - detented at one of two positions. 

1. FORMAT RECAL: 32, -0, +3 tracks from HOME use only during data 
formatting. 

2. RECAL: 72, -0, 4-3 tracks from HOME use to initialize home posi- 
tion after power on or following an access or any other error. 

C. SEEK - coarse track positioning of data head to any desired track 
location. 

D. TRACK FOLLOWING - heads are detented on a specific track location and 
the device is ready for another command. 

E. OFFSET - controlled microstepping of fine position system during 
TRACK FOLLOWING (two modes). 

1. COMMAND OFFSET - direction and amount of offset is specified to 
the servo. 

2. AUTO OFFSET - command allows the servo to automatically move off 
track by the amount indicated by the embedded servo signal on the 
data surface (disk). 

F. STATUS - command can read servo status. 

G. DIAGNOSTIC - not Implemented. 

See Table 1 for the actual command description. With the present com- 
mand structure a SEEK COMMAND can be augmented with an OFFSET COMMAND. 
Upon completion of a seek, the offset command bit is tested to determine 
if an offset will occur following a seek (either auto or command offset). 



* 



* 



When a SERVO ERROR occurs the Z8 SERVO will attempt to do a short RECAL 
(ERROR RECAL). Two attempts are made by the system to do the ERROR RECAL 
function. If either of the two RECAL operations terminate successfully 
the protocol status will be SERVO READY, SIO READY and SERVO ERROR. 
Should the ERROR RECAL fail then the system will complete the error 
recovery by a HOME function. 

The two OFFSET commands will be described. First COMMAND OFFSET is a pre- 
determined amount of micro stepping of the fine position servo. Included 
in the OFFSET BYTE (STATREG) bit B6-0 is a COMMAND OFFSET. Bit B7-1 is a 
forward offset step (toward the spindle); B7»0 is a reverse step. In the 
case bit B6-1 the OFFSET command is AUTO OFFSET. 

AUTO OFFSET command normally occurs during a write operation. When the 
HDA was initially formated at the factory special encoded servo data was 
written on each track "near" the index zone. The reason for this follows: 



Normal coarse and fine position information for the position servos is 
derived from an optical signal relative to the actual data head-track 
location. Over a period of time the relative position (optical signal) 
will not be aligned to the absolute head-track position by some unknown 
amount (less than 100 uln). This small change is Important for reliabil- 
ity during the write operation. Write/Read reliability can be degraded 
due to this misalignment. The special disk encoded servo signal is avail- 
able to the fine position servo and will correct the difference between 
the relative position signal of the optics and the absolute head to track 
position under the data head only at index time. The correction signal 
can be held indefinitely or updated (if desired at each index time) or 
until a new OFFSET command or move command (SEEK or RECAL) occurs. 



II. COMMUNICATION FUNCTIONS 

The servo functions described in the previous section only occur when the 
servo Z8 microprocessor is in the communication state. Communication 
states occur immediately after a system reset, upon completing head set- 
ting after a recal, seek, offset, read servo status or set servo diag- 
nostic. A special communication state exists after a servo error has 
occurred. If + SIO READY is not active no communication can exist between 
the external controller and the servo Z8 processor. 

Servo commands are serial bits grouped as five separate bytes total. Re- 
fer to Table 1 parts I through V as the total communication string. First 
byte is the command byte (i.e. seek, read status, recal, etc.). Second 
byte is the low order difference for a seek (i.e. Byte 2 - $0A is a ten 
track seek). Third byte is the offset byte (AUTO or COMMAND OFFSET and 
the magnitude/ direction for command offset). Fourth byte is the status 
and diagnostic byte (use for reading internal servo status or setting 
diagnostic commands). Byte five is the check sum byte used to check ver- 
ify that the first four bytes were correctly transmitted (communication 
error checking) . 



V 



Part of the communication function requires a specific protocol between 
the servo Z8 processor and the external controller. 

Servo control and communication are described in CHART I. This chart 
illustrates the basic sequencing and control operations. Chart I does 
not illustrate the servo error handling or command/protocol handling 
functions. Error handling is described in Section IV and illustrated by 
CHART II. 



III. Z8 SERVO PROTOCOL 

The protocol between the Z8 SERVO microcomputer and the CONTROLLER is 
based on five I/O lines. Two of the I/O lines are serial input (to Z8 
servo from controller) serial output (from Z8 servo to controller). Data 
stream between the Z8 servo and controller is 8 bit ACSII with no parity 
bit (the fifth byte of the command string contains check sum byte use for 
error checking). There are three additional output lines between the Z8 
servo used as control lines to the controller. Combining the two serial 
I/O lines and the three unidirectional port lines generates the bases of 
the protocol between the Z8 servo and controller. The important opera- 
tions between the Z8 servo and controller are: 

1. Send commands to Z8 servo. 

2. Read Z8 servo status. 

3. Check validity of all four command bytes. 

4. I/O timing signals between the Z8 servo and controller. 

5. Z8 servo reset. 

Sequencing the Z8 servo controller is an important process following a 
Power Dp (Power On Reset) or if the controller should issue a Z8 Servo 
Reset at any time. After a Z8 Servo Reset is inhibited the Z8 I/O ports 
and internal register are initialized. This takes approximately 75 msec 
after the Z8 Servo Reset is inhibited. The protocol baud rate is auto- 
matically set to 19.2KB and then the system is parked at HOME position 
and SIO READY is set active. *** IMPORTANT***. If the desired baud rate 
needs to be increased to 57.6KB; **after a Z8 Servo Reset is the ONLY 
time this can be done***. Once set to 57.6KB the communication rate - re- 
mains at 57.6KB until a Z8 Servo Reset occurs. Setting 57.6KB is achieved 
as follows: 

1. Z8 Servo "Power On 0£ Controller" Reset 

2. Wait for SIO Ready 

3. Send a READ STATUS COMMAND as follows: 

BYTE 1 - $ 00 
BYTE 2 - $ 00 
BYTE 3 - $ 00 
BYTE 4 - $ 87 



After the completion of transmitting the bytes, the Z8 Servo Controller 
chanzges to 57.6KB and will be waiting for the next transmitted command 
at 57.6KB. 

Before the controller transmits the command byte the controller must pole 
the SIO READY line from the Z8 servo to determine if it Is active (+5 
volts). If the line is active then a command can be transmitted to the 
Z8 servo. The program in the Z8 servo will determine what to do with the 
command bytes (depending upon the current status of the Z8 servo). After 
the command (five bytes long) has been transmitted to the Z8 servo, the 
program in the Z8 servo will determine if the command bytes (first four 
bytes) are in error by evaluating the check sum byte (fifth byte trans- 
mitted). See table Chart III and IV for the error handling. After the 
controller has transmitted the last serial string it must wait 250 usee 
then test for SERVO ERROR active (+5 volts). If SERVO ERROR is active the 
command was rejected (check sum error or invalid command). If the SERVO 
ERROR is set active 600 / *sec after the command is sent (and not 250 sec), 
this was a command reject. The SERVO ERROR must be cleared by READ 
STATUS COMMAND or RECAL COMMAND before transmitting another command. 
See CHART 1 for time diagram of the command sequence and I/O protocol. 

As long as SIO READY is active the controller can communicate with the Z8 
Servo Controller. If SERVO READY is not active the only command that will 
cause the Widget Servo to set SERVO READY active is a RECAL COMMAND (NOR- 
MAL or FORMAT) . Read Status will only clear SERVO ERROR. And all other 
commands will be rejected. 

Next, if SERVO READY is active and SERVO ERROR is also active, SERVO 
ERROR can be cleared by: 

1. Any READ STATUS COMMAND. 

2. Any RECAL COMMAND. 

3. Any other commands will be rejected and maintain SERVO ERROR. 

If a SEEK COMMAND is transmitted with both SERVO READY and SERVO ERROR 
active the command will be rejected. 

It is important to check the status of all three status lines from the 
Z8 Servo. It is best to avoid sending a SEEK COMMAND with SERVO READY 
and SERVO ERROR active. 

Chart V parts A-I illustrate some of the serial communication commands 
and error conditions that can occur between the controller and Z8 SERVO. 



IV. ERROR HANDLING 

SERVO ERROR will be generated during the following conditions: 

1. During Recal mode (velocity control only) access time-out. If a Recal 
function exceeds 150 msec then an access timeout occurs. 



During Seek mode (velocity control only) access time-out. If a Seek 
function exceeds 150 msec then an access time-out occurs. 

During Settling mode (following a Recal, Seek, or Offset) if there is 
excessive On Track pulses (3 crossings) indicating excessive head 
motion a Settling error check will occur. 

During a command transmission if a communication error occurs (check 
sum error). 

During a command transmission if a invalid command is sent. 



APPENDIX A: 



I. The purpose of the FINE POSITION SERVO is to maintain detent or lock, on 
a given data track. Any misregistrations of the head/arm due to windage, 
mechanical observed by the optics position signal are corrected by the 
close loop position servo. Misregistrations at the data head relative to 
the actual data track on the disk must be corrected by the AUTO OFFSET 
command. Figure I illustrates a block diagram of the Widget FINE POSI- 
TION SERVO. The amount of misregistration at the data track sensed after 
a AUTO OFFSET command are summed Into the servo and the servo is automat- 
ically repositioned over the data track. 

II. The COARSE POSITION SERVO (SEEK) has the function of moving the data 
head arbitarily from a current track to any other arbitrary track loca- 
tion within the total number of track locations between the inner to 
outer crash stops. When a command is transmitted to the Z8 Servo con- 
troller, the Z8 decodes and interprets the command into a servo function. 
If a SEEK command is sent to the Z8 Servo Controller a direction and 
number of tracks to move is also sent. The system starts its move to the 
new track location. When the arm has moved to its new location the Z8 
Servo Controller provides control and delay necessary to allow the data 
head and the FINE POSITION SERVO to come to rest immediately following a 
SEEK. This insures that motion In FINE POSITION SERVO and data head will 
be under control when the READ /WRITE channel begins operation. Reliabil- 
ity of the data channel is assured with high margins. Figure I illustrates 
a block diagram of the Widget COARSE POSITION SERVO. 

The differences between the FINE POSITION SERVO and the COARSE POSITION 
SERVO is handled by the Z8 Servo Controller. The two servos share for 
the most part the same set of electronics. The Z8 Servo Controller and 
analog multiplexers switch between the signal paths. In general there 
are some circuits that are not shared because of their uniqueness for a 
particular servo. 



s 



APPENDIX B: 



An important part of the Widget Servo System is the optics signal. The optics 
signal provides the necessary signals for the five position servo position the 
data head accurately over the data track and to provide the system velocity 
signal during seek mode. The alignment of the optics signal is described in 
the following section on "WIDGET OPTICS ALIGNMENT PROCEDURE." 
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WIDGET SERVO 
VARIOUS KEY WAVEFORMS 



CONTENTS 



Page 1 Optics Adjustment 

Page 2 Current Sense and Position A 

Page 3 Current Sense and Position A (Forward and Rev Seeks) 

Page 4 Velocity and Position A 

Page 5 Velocity and Position A (Forward and Rev Seeks) 

Page 6 DAC Output and Position A 

Page 7 DAC Output and Position A (Forward and Rev Seeks) 

Page 8 Curve Shift Function and Position A ( 1 track seek) 

Page 9 Curve Shift Function and Position A (60 track seek) 



WAVEFORM: Optics Adjustment 



Scope Adjustments: 

Channel 

Chan 1 
Chan 2 
Trig In 



Probe Tip 

Position A 
Position B 
Not used 



Test Point 

TP9 
TP 8 



Notes 

2V/div 
2V/div 



Horiz 



X-Y Mode 



Servo: 

Alternate Seeks, 512 tracks 

Press Z; 82, 0, 0, 

86, 0, 0, 




PAGE 1 



WAVEFORM: Current Sense and Position A 



Scope Adjustments: 

Channel Probe Tip 



Chan 1 
Chan 2 
Trig In 



Current Sense 
Position A 
Access Mode 



Test Point 

TP19 
TP 9 
TP27 



Notes 

5V/div 
5V/div 

Positive trig, Ext/ 10 



Horiz: 5ms/Div Calibrated 



, Servo: 

Alternate Seeks, 96 tracks (Hex $60) 

Press Z; 80, 60, 0, 

84, 60, 0, 




WAVEFORM: Current Sense and Position A 
(Forward and Reverse Seeks) 



Scope Adjustments: 

Channel 

Chan 1 
Chan 2 
Trig In 



Probe Tip 

Current Sense 
Position A 
Access Mode 



Test Point Notes 

TP19 5V/div 

TP9 5V/div 

TP27 Positive trig, Ext/ 10 



Horiz: 2ms/Div Uncalibrated 



Servo: 



Alternate Seeks, 96 tracks (Hex $60) 



Press Z; 



80, 60, 0, 
84, 60, 0, 
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WAVEFORM: Velocity and Position A 



Scope Adjustments: 

Channel 

Chan 1 
Chan 2 
Trig In 



Probe Tip 

Velocity 
Position A 
Access Mode 



Test Point 

TP7 
TP 9 
TP27 



Notes 

2V/div 
5V/div 

Positive trig, Ext/ 10 



Horiz: 5ms/Div Calibrated 



Servo: 



Alternate Seeks, 96 tracks (Hex $60) 



Press Z; 



80, 60, 0, 
84, 60, 0, 
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WAVEFORM: Velocity and Position A 
(Forward and Rev Seeks) 



Scope Adjustments: 

Channel 

Chan 1 
Chan 2 
Trig In 



Probe Tip 

Velocity 
Position A 
Access Mode 



Test Point 

TP 7 
TP 9 
TP27 



Notes 

5V/di'v 
5V/div 

Positive trig, Ext/ 10 



"Horiz: 2ms/Div Uncalibrated 



Servo: 

Alternate Seeks, 96 tracks (Hex $60) 

Press Z; 80, 60, 0, 

84, 60, 0, 




WAVEFORM: DAC Output and Position A 

* 



Scope Adjustments: 

Channel 

Chan 1 
Chan 2 
Trig In 



Probe Tip 

DAC Output 
Position A 
Access Mode 



Test Point 

TP 13 

TP9 

TP27 



Notes 

2V/div 
5V/div 

Positive trig, Ext/10 



Horiz: 5ms/Div Calibrated 



Servo: 

Alternate Seeks, 96 tracks (Hex $60) 

Press Z; 80, 60, 0, 

84, 60, 0, 




WAVEFORM: DAC Output and. Position A 
(Forward and Rev Seeks) 



Scope Adjustments: 
Channel 



Chan 1 
Chan 2 
Trig In 



Probe Tip 

DAC Output 
Position A 
Access Mode 



Test Point 

TP 13 
TP 9 
TP27 



Hori2: 2ms/Div Uncalibrated 



Notes 

2V/div 
5V/div 

Positive trig, Ext/ 10 



Servo: 

Alternate Seeks, 96 tracks (Hex $60) 

Press Z; 80, 60, 0, 

84, 60, 0, 




WAVEFORM: Curve Shift Function and Position A 
(Forward and Rev Seeks: 1 track) 



Scope Adjustments: 

Channel 

Chan 1 
Chan 2 
Trig In 



Probe Tip 



Test Point 



Curve Shift Func. TP 12 
Position A TP9 
Access Mode TP27 



Notes 

2V/div 
5V/div 

Positive trig, Ext/10 



Horiz: 2ms/Div Uncalibrated 



Servo: 

Alternate Seeks, 1 track 

Press Z; 80, 01, 0, 

84, 01, 0, 
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WAVEFORM: Curve Shift Function and Position A 
(60 track seek) 



Scope Adjustments: 
Channel 

Chan 1 
Chan 2 
Trig- In 



Probe Tip 



Test Point 



Curve Shift Func. TP 12 
Position A TP 9 

Access Mode TP27 



Notes 

2V/div 
5V/div 

Positive trig, Ext/10 



Horiz: 5ms/Div Calibrated 



Servo: 

Alternate Seeks, 96 tracks (Hex $60) 

Press Z; 80, 60, 0, 

84, 60, 0, 




Z8 SERVO COMMAND BYTES 
TABLE 1 



page 1 



I. BYTE li COMMAND BYTE (DIFCNTH) 







• 

i 


B7 


B6 


B5 


B4 1 


FUNCTIONS 








1 t 


1 


8 


8 


8 : 


access only 






IB7 




1 


8 


8 


i 


access with offset 




command 


\B6 


H « 


8 


1 


8 


8 


normal recal <to trk 


72) 


bi ts 


SB5 


7- S 


8 


1 


1 


1 


1 format recal < to trk 


32) 




!B4 


> i 


8 


8 


e 


1 


offset-trk following 








C * 1 


1 


1 


8 


8 


i home-send to ID stop 








i \ 


8 


8 


l 


8 


diagnostic command 






I B3 -X- not 


used o t 


8 


8 


8 


8 


i read status command 




tcctss 


tB2 -Access 


direction 













bits SB1 -hi diff2 (512) 
!B9 -hi diffl (256) 



access direction 




1 


< FORWARD i toward the spindle) 




m 


8 


< REVERSE: away from the spindle) 


hi dlff2 (512) 




1 


<S12 tracks to go) 






8 


(not set) 


hi diffl (256) 




1 


(256 tracks to go) 






8 


(not set)- 



II. BYTE 2 i DIFF BYTE (DIFCNTL) 

command BYTE 2 contains the LOU) ORDER DIFFERENCE COUNT for a seek 



t B7 -bi t7- 128 tracks 

IB6 -bit*- 6A tracks 

IBS -bi t5- 32 tracks 

}B4 -bi t4» 16 tracks 

5B3 -bi t3» 8 tracks 

I B2 -bi t2- 4 tracks 

IB1 -bi tl- 2 tracks 

SB8 -bi t8- 1 track 



Z8 SERVO COMMAND BYTES 
TABLE 1 



P*Qe2 



III. BYTE 3t OFFSET BYTE ( STATREG ) 

command BYTE 3 con ta In* the INSTRUCTION -for an OFFSET COMMAND (seek 
or during track -foil owing) 



- p 



OF 





IB7 


V 


\B6 




(85 


—4 


!B4 




!B3 




!B2 




!B1 




IB8 



'16 

'■Q 
«4 



1. if offset command -from BYTE 1 is followed by bit* set <auto offset) 
offset direction <bi t7) read offset <bit5) and bits 4-8 are ionored 
but should be set to if not used. 

2. OFFSET DIRECTION -1 (FORWARD OFFSET i toward the spindle) 

-8 (REVERSE OFFSET i away from the spindle) 



3. AUTO OFFSET 



4. READ OFFSET 



»l (normally used preceeding a write operation) 
•8 (manual offset rMUST send direction and maonitud 
of offset) 



-1 (read offset value from DACji.e 

offset) 
■0 (no action) 



after auto 



* READ OFFSET COMMAND desired after AUTO OFFSET MUST be sent as two 
seperate commands 



IV. BYTE 4 1 STATUS BYTE (CNTREG) 



IB7 -communication rate 
\B6 -power on reset 
!BS -not used 
!B4 -not used 

1B3 -status or diagnostic bits 
IB2 - I 
2B1 - | 
SB8 - V 



B?«8j Communication Rate is 19.2 KBAUD 
-1} Communication Rate is 57.6 KBAUD 



B6*8; Power On Reset bit is no active 
-1 j Power On Reset bit is active 



28 SERVO COrt^D BYTES 
TABLE 1 



p*g»3 



V. BYTE 5: CHECKSUM BYTE <CKSUM> 



CB7 B6 B5 B4 B3 B2 Bl B8 3 

results of the transmitted CHECKSUM BYTE are derived *s: 



<BYTE 1 ♦ BYTE 2 ♦ BYTE 3 + BYTE 4) - CHECKSUM BYTE 
<♦> is defined as the addition o-f each BYTE 



(BYTE) is defined as the compliment of the BYTE <l-4) 

VI . The SERVO STATUS Tines <SIO RDY, SERVO ROY, SERVO ERROR) must have the 
■following conditions in order to send the listed Z8 COMMANDS i 

SERVO STATUS 







s 


S 


s 






i 


R 


R 









V 


V 






R 


R 


E 






D 


D 


R 






Y 


Y 


R 


Z8 SERVO CMD 


HEX 








access(on1 y) 


8X 




1 


t 

8! 


access<of f set) 


9X 




1 


81 ' 


recal ( data) 


48 




X 


Xi 


recal < format) 


78 




X 


XJ 


park 


C8 




X 


XI 


offsetCdetent) 


ie 




1 


8! 


status 


ee 




X 


XJ 


di agnost i c 


28 
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